Consider making "header_upstream Host {host}" the default setting for proxy.
I have the following setup:
Web Browser --- HTTP/2 --> Caddy as reverse proxy --- HTTP/1.1 --> Node.js
The way it currently works regarding to the Host header is the following:
This is what the HTTP/2 spec says about the :authority header:
An intermediary that converts an HTTP/2 request to HTTP/1.1 MUST create a Host header field if one is not present in a request by copying the value of the ":authority" pseudo-header field.
In order to make Caddy to copy the value of the :authority header, one has explicitly tell Caddy to do so, either with the preset transparent or by using "header_upstream Host {host}". Because of copying the value of :authority header in the absence of a Host header is required by the spec, I'd argue, that Caddy should do it automatically, without any additional configuration.
Please find the relevant discussion on the forum as well.
Cool, thanks. To clarify for other participants, I don't think this is necessarily so much about spec compliance as it is about whether transparent should be the default setting for proxying.
Can we think of any reason transparent _shouldn't_ be the default setting? I can't see any downside, and they can obviously still be overridden if this behaviour is not desired (which I think would be far less frequently than it _is_ desired).
I for one like it when transparent is off by default. I almost never use it. Case in point: https://twitter.com/mholt6/status/858356637937016832
IMO, it's also nice to be transparent (i.e. self-reporting) about being transparent. :wink:
And, in my experience, the only upstreams that _require_ the host name to be rewritten are those apps which redirect seemingly unnecessarily (i.e. they could be using host-relative paths, like /path, instead of the full URL). Why are they trying to control the hostname (they aren't the web server)?
This is just my opinion/preference. I'm not opposed to a change, but the transparent preset is so nice and elegant. An inverse solution that is equally nice and elegant would have to be found _if_ we make a change. (Also, transparent does change more than just the Host header; might be worth considering the scope of this discussion. I guess originally it's just about the Host header, but if you're passing it through, being a good netizen requires setting those other headers too.)
I'm of the mind that because transparent is a preset this shouldn't be defaulted. Let me explain further.
We use the presets to provide a group of proxy configuration. Changing this to be an inverse relationship in this instance goes against the other directives that have the preset style of configuration. Perhaps simply fixing this 'bug' where HTTP/2 is proxying to HTTP/1.1 that should include the Host header to match spec would be good. But further changes to make a 'inverse preset' might do more harm than good.
Good points, @slightfoot.
Let's leave it the same for now, then: transparent _not_ as the default. It's very easy to turn on, and is more obvious how the proxy works this way.
Discussion still welcome, of course, in case there's anything new to add, but closing the issue anyway.
Most helpful comment
I'm of the mind that because
transparentis a preset this shouldn't be defaulted. Let me explain further.We use the presets to provide a group of proxy configuration. Changing this to be an inverse relationship in this instance goes against the other directives that have the preset style of configuration. Perhaps simply fixing this 'bug' where
HTTP/2is proxying toHTTP/1.1that should include theHostheader to match spec would be good. But further changes to make a 'inverse preset' might do more harm than good.