New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

net/http: add knobs for which headers Client forwards on redirect? #19973

zachgersh opened this Issue Apr 14, 2017 · 4 comments


None yet
3 participants

zachgersh commented Apr 14, 2017

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?


What operating system and processor architecture are you using (go env)?


What did you do?

Making a request to upload a file that is setting the content-type of application/x-compressed which results in a successful 302 redirect to a task monitoring endpoint.

What did you expect to see?

The request succeeds and the task monitoring endpoint returns a 200.

What did you see instead?

The endpoint fails due to the fact that it has received the additional header.

I know I can implement a CheckRedirect function that would allow me to strip out the headers but it seems like the go 1.7.X behavior was more desirable (providing the function to forward the headers).

It actually might be nice to make this a flag on the client (so headers can be optionally be forwarded or not). Having to implement CheckRedirect just to not send along headers feels a tad bit heavy handed but I am open to it.

I also know that the API server, which I have no control over, could be modified to ignore additional headers but the code I have talking to this server worked in 1.7.X and now doesn't work in 1.8.1 (slightly surprising).

@bradfitz bradfitz changed the title from net/http/client - forwarding of all headers on redirect sometimes bad? to net/http: add knobs for which headers Client forwards on redirect? Apr 14, 2017


This comment has been minimized.


bradfitz commented Apr 14, 2017

For 8 releases people complained about the lack of header forwarding and we kept putting it off and thinking about it. And then we did it, and... this. :)

I'll entertain proposals but I don't have the resources to think about this more and design the API myself.

@bradfitz bradfitz added this to the Unplanned milestone Apr 14, 2017


This comment has been minimized.

zachgersh commented Apr 14, 2017

@bradfitz I almost dreaded putting this in because it felt like a "damned if you do, damned if you don't" sort of behavior. I'd be glad to take this on and rough it out, of course as long as you are willing to provide feedback 😄

Easiest solution:

Client now takes a bool for RedirectHeaders.

I'd love to see if anyone else has run into this and/or cares. Also, thanks for all you do and even being open to the idea.


This comment has been minimized.


bradfitz commented Apr 14, 2017

We're not going to make the behavior off in 1.0-1.7, on in 1.8, and off again in 1.9. It's going to be on by default now. So any bool would need to turn it off, so would need a different name.

But a bool might not be flexible enough. A func(string) bool might be better. A per-key policy func or something. And then there could be predefined funcs/vars for AllowAll or AllNone. And a nil func (the default) would be a Go-defined policy, like we have in 1.8.


This comment has been minimized.

gopherbot commented Feb 21, 2018

Change mentions this issue: net/http: optionally add headers on redirect

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment