Host: header and proxy

[di...@covalent.net]

Some advice needed on how to use the Host header when using a proxy and
confirming its limitations with respect to Host: based proxies.

-	Consider a proxy proxy.com on port PA

-	Consider an origin server or gateway on server.com on port PB

-	Consider a URL:	http://server.com[:PB]/foo.html

>From RFC 2616 - 14.23 - the Host header MUST reprsent the naming authority
of the origin server. (And one MUST use the Host: header when one is doing
HTTP/1.1 (19.6.1.1 - assuming it applies to a client doing a proxy
request)).

So I need to do

	tcp-connect( IP-of("proxy.com"), PA)
	send(
		GET http://server.com:PB/foo.html HTTP/1.1
		Host: server.com:PB
		...

And the proxy MUST discard the Host: header according to 5.2.1 as there
is an absoluteURI.

So questions

-	This is correct ?

-	Now how I connect to a Host: based proxy ?
	-> seems impossible.

-	Why is the Host: header there in this case - as it adds
	no information and it only can cause conflicts (i.e.
	an application for getting about 5.2.1).

I.e. it seems to make that it almost makes more sense to do
as a client during a proxy request:

	connect( IPof("proxy.com"), PA)
	send(
		GET http://server.com/foo.html HTTP/1.1
		[Proxy-]Host: proxy.com:PA
		.....

much along the lines of Proxy-Authenticate et.al.

DW

-- 
Dirk-Willem van Gulik

Re: Host: header and proxy

[Taisuke Yamada <ta...@iij.ad.jp>]

> 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 <ta...@iij.ad.jp>
Internet Initiative Japan Inc., Technical Planning Division