W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2010

Re: HTTPbis -10 drafts published : Connection header

From: Adrien de Croy <adrien@qbik.com>
Date: Thu, 15 Jul 2010 12:45:19 +1200
Message-ID: <4C3E5A1F.3010809@qbik.com>
To: Willy Tarreau <w@1wt.eu>
CC: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>

that's quite an interesting scenario

if a proxy were to receive a request message with say

Connection: content-type

in it, what do you think should the proxy do?

a) ignore it (not remove Content-Type)
b) reject the message (client attempted exploit)
c) something else

it may be clear enough for Content-Type, but what about some other 
header (e.g. header not known about by the proxy).  Should we have a 
requirement that a proxy should reject any message that has a token in 
the Connection header that is not a known hop-by-hop header?

regards

Adrien


On 14/07/2010 8:55 p.m., Willy Tarreau wrote:
> Hi,
>
> On Tue, Jul 13, 2010 at 08:18:10AM +0200, Julian Reschke wrote:
>    
>> <http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-10#appendix-D.11>
>>      
> Here I have found something that ought to be clarified concerning
> the Connection header :
>
> 9.1. Connection
>     HTTP/1.1 proxies MUST parse the Connection header field before a
>     message is forwarded and, for each connection-token in this field,
>     remove any header field(s) from the message with the same name as the
>     connection-token.  Connection options are signaled by the presence of
>     a connection-token in the Connection header field, not by any
>     corresponding additional header field(s), since the additional header
>     field may not be sent if there are no parameters associated with that
>     connection option.
>
>     Message headers listed in the Connection header MUST NOT include end-
>     to-end headers, such as Cache-Control.
>
> The last sentence is already very important, but some side effects
> remain on some implementations, because it is not stated that only
> headers that were given by the client must be removed. If you take
> Apache 2.2 as a proxy for instance, by default it will add an
> "X-Forwarded-For" header when forwarding the connection to the
> server, to indicate the client's address. If the client says
> "Connection: X-Forwarded-For", then this header is removed from the
> output and the server does not get the client's address. I've not
> checked the code, but I think this is because the header cleaning
> happen just before forwarding the connection, and after header
> addition. This can permit a client to alter the semantics of the
> communication between a proxy and a server, possibly bypassing some
> filtering or hiding its activities. I think that adding a sentence
> such as the following would be fine :
>
>     If an HTTP/1.1 proxy intends to modify or add headers to the
>     message being forwarded, it may only do so after the headers
>     above have been removed.
>
> I've also tried to remove "Connection" (which is a hop-by-hop header)
> with Apache and fortunately it did not work. Out of curiosity I tried
> with "Content-Length" and "Host" and they did not work either.
> However, when I try to remove "Transfer-Encoding" (hop-by-hop) on a
> POST with empty body, I observe that "Content-Length: 0" is not added
> to the request, which is harmless (the request will be rejected due
> to missing content length).
>
> I've just found that other end-to-end headers such as "cache-control",
> "content-encoding" etc... can still be removed via Apache, possibly
> leading to differences in contents interpretation between the proxy
> and the server (eg: when content filtering is performed), though this
> is purely implementation-specific. However, implementation-specific
> differences or limitations sometimes indicate a difficulty in fully
> understanding or respecting a standard.
>
> Regards,
> Willy
>
>
>    
Received on Thursday, 15 July 2010 00:46:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:23 GMT