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: StripPrefix drops context value set by down-stream handler #21784
Comments
A quick fix would be
|
Note that |
@mvdan Is there an idiomatic way to pass back context value to upstream handler? |
Well, I guess what you're doing - modifying the request in-place - is as good as it gets. But it goes against the design of a request's context, so using the standard library will be painful - the request may be copied and the pointer changed, as you have seen. The question to ask here is likely why you'd need a variable to go back to the upstream handler in the first place. I don't think using contexts is a good idea, as they're for the exact opposite. I would suggest taking this to https://github.com/golang/go/wiki/Questions, as the issue tracker is used for bugs, not questions. |
I've update the demo codes to reflect what the real codes used to be doing before 1.9. I can workaround the limits of StripPrefix by passing a setter function in context to downstream handler and call it to pass back something. |
I have the same question. StripPrefix is almost certainly not going to change. The composition seems backwards in your example. I would nest the handler within the StripPrefix handler, rather than visa-versa as your example does. e.g.: http.Handle("/foo/", http.StripPrefix("/foo/", func(rw http.ResponseWriter, r *http.Request) {
... this code can modify r however it wants ...
})) I'm closing this because I don't see a bug, but if you find a bug or have a more detailed feature request, please reopen. |
What did you do?
What did you expect to see?
The commented out handler without StripPrefix outputs as above.
What did you see instead?
Does this issue reproduce with the latest release (go1.9)?
yes
System details
The text was updated successfully, but these errors were encountered: