core: add modular network_proxy support
#6399
Conversation
Co-authored-by: @ImpostorKeanu Signed-off-by: Mohammed Al Sahaf <[email protected]>
mohammed90
added
in progress 🏃♂️
|
Slick! I support everything about this! |
Signed-off-by: Mohammed Al Sahaf <[email protected]>
mohammed90
force-pushed
the
forward-proxy
branch
from
91e0eb9 to
5436774
Compare
Signed-off-by: Mohammed Al Sahaf <[email protected]>
| @@ -139,6 +139,9 @@ type HTTPTransport struct { | |||
| // The pre-configured underlying HTTP transport. | |||
| Transport *http.Transport `json:"-"` | |||
|
|
|||
| // Forward proxy module | |||
| @@ -1074,6 +1074,22 @@ func (h *HTTPTransport) UnmarshalCaddyfile(d *caddyfile.Dispenser) error { | |||
| } | |||
| h.ForwardProxyURL = d.Val() | |||
|
|
|||
| case "forward_proxy": | |||
There was a problem hiding this comment.
If it's "network_proxy" should that be the option name in Caddyfile?
There was a problem hiding this comment.
I was on the fence. I've changed them all to network_proxy.
| caddy.RegisterModule(ProxyFromNone{}) | ||
| } | ||
|
|
||
| // The "url" proxy source uses the defined URL as the proxy |
There was a problem hiding this comment.
Don't we usually start godoc comments with the name of the type as the first word? I don't know why that's the convention but I think that's what we typically do?
There was a problem hiding this comment.
It's a Go idiom. However, we pick up the same doc lines for our documentation, so I had to make a judgement call to either make it sensible for our documentation or meet the informal convention of Go docs. It's less confusing for our users to see the module name instead of the other way around.
Co-authored-by: Francis Lavoie <[email protected]>
Signed-off-by: Mohammed Al Sahaf <[email protected]>
The PR #5369 introduced support for the standard env vars
HTTP_PROXY,HTTPS_PROXY, andNO_PROXYin thereverse_proxyhandler. The ACME client in Caddy has always respected the vars. The issue #6111 shows a need for configurable forward-proxy outside the env vars due to the global state of env vars.The post (https://caddy.community/t/routing-acme-requests-via-http-proxy/24363) in the Caddy forum shows a need for forward-proxy support for ACME (external requests) but not for reverse-proxy upstreams. Again, the global state nature of the env vars impedes any effort to separate those concerns.
To brainstorm the best solution, I'm introducing modular approach, where the proxy address can be explicitly configured via module and falls back to env var. Discussion and iteration on this PR is necessary to ensure a common satisfactory solution is reached. I haven't wired up the Caddyfile parts.
CC/ @ImpostorKeanu
Note if this approach is acceptable, the
ForwardProxyURLfield will be deprecated in favor of the"from": "url"module.TODO: