-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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/httputil: replace Director with Rewrite #53002
Comments
This proposal has been added to the active column of the proposals project |
I am bike shedding, but I do not see discussion in #50580, so I will ask here: what is the benefit to the // This is the equivalent of httputil.NewSingleHostReverseProxy(someURL).
proxy := httputil.ReverseProxy{
Rewrite: httputil.Rewrite{
SetXForwarded: true,
SetURL: someURL
}
} |
The proposed |
Should have been more clear:
Yep, sorry the example pigenholed my thinking; that makes sense. That said, why then would we not make it You could also have two inputs if void is desirable: |
Wrapping both requests up in a |
No that makes sense, there has already been some preprocessing done to create a populated // This is the equivalent of httputil.NewSingleHostReverseProxy(someURL).
proxy := httputil.ReverseProxy{
Rewrite: func(in, out *http.Request) { ...}
}
Yeah, if we see a clear need to add new struct fields or methods that include magic [recte internal apis], I can see this being useful; it just feels like a novel design pattern akin to grpc input structs, which feel decidedly non go-like. I just prefer the obvious nature of my explicit format. |
Have we resolved the objections to Rewriter? |
Perhaps there's a better name than Landing this early in 1.20 would be nice. Looking through issues that mention Primary motivation for this proposal (and sufficient to justify it, I believe, since this is a security concern): Issues related to forwarding headers (
Issues related to |
Possibly better name than |
Change https://go.dev/cl/407214 mentions this issue: |
CL 407214 contains an implementation of this proposal, with a few changes from the original post:
The The |
If we're clearing |
Yes, I'm actually already clearing |
FWIW when I said "objections to Rewriter" I meant this proposal generally, not the name. We should use whatever name you think is clearest; Rewriter is fine if so. Does anyone object to trying this in Go 1.20? |
Based on the discussion above, this proposal seems like a likely accept. |
No change in consensus, so accepted. 🎉 |
Change https://go.dev/cl/450515 mentions this issue: |
For #41773 For #41773 For #50465 For #51914 For #53002 For #53896 For #53960 For #54136 For #54299 Change-Id: I729d5eafc1940d5706f980882a08ece1f69bb42c Reviewed-on: https://go-review.googlesource.com/c/go/+/450515 Auto-Submit: Damien Neil <dneil@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Damien Neil <dneil@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
This proposal seeks to address #50580. The quick summary for the motivation is that the ReverseProxy request-rewriting hook needs to make a clear distinction between the request received by the proxy and the forwarded request sent by the proxy. The existing Director hook does not make this distinction, resulting in unsafe behavior. See #50580 for details.
I propose adding a
Rewrite
hook tohttputil.ReverseProxy
, superseding the existingDirector
hook.Rewrite
will take a*httputil.Rewriter
parameter. TheRewriter
will provide the inbound and outbound requests, as well as convenience methods for modifying the outbound request.A
ReverseProxy
with aRewrite
function will default to making minimal modifications to the outbound request. In particular, it will not addX-Forwarded-*
headers by default. Methods onRewriter
will provide an easy way to add these headers if desired:Rewriter.SetXForwarded
to add headers (replacing any sent by the client) orRewriter.AppendXForwarded
(appending to ones sent by the client, the current default behavior). This imposes a small additional requirement on users ofReverseProxy
, but makes the proxy behavior explicit and easier to change in the future.Proposed API additions:
Example usage:
A draft implementation is in https://go.dev/cl/407214.
The text was updated successfully, but these errors were encountered: