> Some advice needed on how to use the Host header when using a proxy
> and confirming its limitations with respect to Host: based proxies.
I personally do think reusing Host: header for proxy with name-based
virtualhost configuration is a nice tweak in implementation.
It seems RFC2616 does not explicitly forbid such a configuration. But
on the other hand, it is not clear how HTTP proxy should handle Host:
header. There seems there are at least three MUST requirements related
to the issue:
- Host: header MUST be ignored when absolute URI is given (5.2.1)
- Host: header MUST represent the naming authority of the origin server
or gateway given by the original URL (14.23)
- End-to-end header in request is expected to be transmitted to
ultimate destination (13.5.1 + 14.20).
Note: In 13.5.1, only response is mentioned as a "MUST". But in
14.20, request is also mentioned as a "MUST" regarding to
Expect: header.
My current interpretations are:
- From the context, it seems 5.2.1 was written with caching HTTP
proxy server in mind, not the one with name-based virtualhost
configuration.
- It seems "gateway" in 14.23 is considering reverse-proxy configuration
where hostname in the URL is a frontend to the ultimate destination of
the resource. This, I guess, means hostname in Host: header and absolute
URI in request line must match, or that's a invalid HTTP request.
- As 13.5.1 does not define Host: as hop-by-hop header, I assume
it is not expecting Host: header as an information used to control
behavior of HTTP proxy server.
Again, I do consider using Host: header to specify proxy server
running on virtualhost configuration is a nice tweak in implementation,
and it's probably not a RFC violation. But it seems it's not safe
to assume this behavior with other products.
For this Host: header, HTTP clients I tested (libwww-w3c, libwww-perl,
wget, curl, Internet Explorer, Mozilla) never generated Host: entry
pointing to the proxy, so even though server side may be capable of
such a configuration, client side is not.
Regards,
--
Taisuke Yamada <[EMAIL PROTECTED]>
Internet Initiative Japan Inc., Technical Planning Division
