W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2014

RE: HTTP/1.1 proxy behavior when Host differs from absoluteURI

From: Richard Wheeldon (rwheeldo) <rwheeldo@cisco.com>
Date: Thu, 13 Mar 2014 08:48:54 +0000
To: "Roy T. Fielding" <fielding@gbiv.com>, Amos Jeffries <squid3@treenet.co.nz>
CC: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <0566CA5E9B906D40B6737DD47DA9FB8F1AE454F4@xmb-rcd-x04.cisco.com>
It's not. Apologies. Ignore me. I was looking at the wrong doc,


-----Original Message-----
From: Roy T. Fielding [mailto:fielding@gbiv.com] 
Sent: 13 March 2014 03:59
To: Amos Jeffries
Cc: ietf-http-wg@w3.org
Subject: Re: HTTP/1.1 proxy behavior when Host differs from absoluteURI


Section 5.4 (Host) of p1 says:

   When a proxy receives a request with an absolute-form of request-
   target, the proxy MUST ignore the received Host header field (if any)
   and instead replace it with the host information of the request-
   target.  A proxy that forwards such a request MUST generate a new
   Host field-value based on the received request-target rather than
   forward the received Host field-value.

How on earth can that be considered ambiguous?


On Mar 11, 2014, at 2:50 PM, Amos Jeffries wrote:

> On 2014-03-12 06:33, Richard Wheeldon (rwheeldo) wrote:
>> I think it's ambiguous. Squid will change the host to match that 
>> found in the URI. Our CWS proxy will simply disallow and reject the request.
>> This is not compliant but no-one has ever complained and I don't 
>> think I see any legitimate use case for allowing this. It also smells 
>> like there could be a vulnerability to exploit in certain circumstances.
>> Don't expect it to work well in practice.
> Cache Poisoning. The security all the way to the server is predicated on the URL. Then the final proxy in the chain always faces the choice when mapping to partial-URL between retaining the Host header (poisoning the client response) and replacing the Host header with the value from absolute-URI.
> It could also punt and send the absolute-URI and host header to the server But under section 5.1 that is the same as replacing it whenever the server is compliant.
> While undefined there only seems to be one safe choice: replace the Host header.
> FTR: Squid seems to have been doing its replacement since the beginning of HTTP/1.1 without trouble.
> Amos
>> Regards,
>> Richard
>> From: Daniel Sommermann [mailto:dcsommer@fb.com]
>> Sent: 11 March 2014 16:35
>> To: HTTP Working Group
>> Subject: HTTP/1.1 proxy behavior when Host differs from absoluteURI 
>> What is the correct behavior for a (forward) proxy that receives a 
>> request with an absoluteURI that differs from the Host header? 5.1.2 
>> suggests that the Host header should be ignored ("Note that the proxy 
>> MAY forward the request on to another proxy or directly to the server 
>> specified by the absoluteURI"). 5.2 seems to suggest the same, but 
>> this section is scoped to the behavior of the origin server, not for 
>> a proxy.
>> If the Host header should be ignored for forwarding by the proxy, 
>> should the Host header be stripped or forwarded to the next hop?
Received on Thursday, 13 March 2014 08:49:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:24 UTC