On Nov 16, 2016 20:29, "Jacob Champion" <champio...@gmail.com> wrote: > > On 11/16/2016 05:01 AM, William A Rowe Jr wrote: >> >> We need to tolerate their presence. But we should ignore the guidance that >> sf originally quoted, that the URI host supersedes the Host header, it does >> not, they are two different entities it the proxy case > > > The "different entities" interpretation made sense to me too, but after re-reading the spec and seeing what the browsers actually do, I'm not so sure. (I'm a relative noob when it comes to the proxy sides of the spec, so corrections are appreciated.) > > From section 5.4: > > A client MUST send a Host header field in all HTTP/1.1 request > messages. If the target URI includes an authority component, then a > client MUST send a field-value for Host that is identical to that > authority component, excluding any userinfo subcomponent and its "@" > delimiter (Section 2.7.1). If the authority component is missing or > undefined for the target URI, then a client MUST send a Host header > field with an empty field-value. > > That's pretty absolute, and there doesn't seem to be an exception carved out for proxies. And in practice, after giving Chromium and Firefox a try with a local netcat "proxy", the Host headers they send are indeed derived from the target URI, *not* the hostname of the HTTP proxy. I'd like to see what other browsers do as well. > > This would appear to prevent name-based hosting of multiple proxies and origin servers at the same IP address, which seems strange to me, given that the Host header would be an appropriate resolution tool in that case... so I'm hoping there's something I'm missing. > > Maybe no one needs to do that? Does anyone have experience with a client/user-agent that makes use of name-based virtual proxies? > > --Jacob
Doh, that's right. This is why we had such a horrid time with unwarranted TLS SNI host headers vs Host: headers for proxy requests through httpd:. I will need to review all three and compare them to the effect of this new patch. In the interim I suggest we withdraw this comparison, and bring it back up as a post 2.4.24 change. Thoughts?
