[prev in list] [next in list] [prev in thread] [next in thread] 

List:       squid-dev
Subject:    Re: 1xx response forwarding and ignore_expect_100
From:       Alex Rousskov <rousskov () measurement-factory ! com>
Date:       2010-08-25 2:04:56
Message-ID: 4C747A48.7020007 () measurement-factory ! com
[Download RAW message or body]

On 08/24/2010 06:05 PM, Henrik Nordström wrote:
> tis 2010-08-24 klockan 17:16 -0600 skrev Alex Rousskov:
>
>> RFC 2616 implies that we must forward 100-continue to HTTP/1.0 clients
>> that send Expect: 100-continue header
>
> I know, and something I disagree with. HTTP/1.0 says:
>
> 9.1  Informational 1xx
>
>     This class of status code indicates a provisional response,
>     consisting only of the Status-Line and optional headers, and is
>     terminated by an empty line. HTTP/1.0 does not define any 1xx status
>     codes and they are not a valid response to a HTTP/1.0 request.
>     However, they may be useful for experimental applications which are
>     outside the scope of this specification.
>
> Plus 7.2  Entity Body
>
>     All 1xx (informational), 204 (no content), and
>     304 (not modified) responses must not include a body.
>
> which makes 1xx forwarding via a HTTP/1.0 proxy practically impossible.

I do not see what in the above language makes forwarding impossible, but 
I do agree that many proxies, including HTTP/1.1 proxies do not 
implement this forwarding correctly.

> At the same time HTTP/1.0 says nothing about Expect or Via.
>
> Result is very likely breakdown if there is an HTTP/1.0 proxy in the
> path as thi to the HTTP/1.1 server is indistinguisible from an directly
> connected HTTP/1.0 client using Expect: 100-continue.
>
> Not sure we have discussed this on HTTPbis. Dropped a mail there now to
> discuss this.

Please keep us posted, but I suspect that sooner or later we will learn 
about an HTTP/1.0 client sending Expect regardless of HTTPbis actions. 
Thus, we probably have to support both forwarding and dropping of 100 
Continue. The drop_expect_100 option, if added, can be used to disable 
currently-compliant behavior.

Thank you,

Alex.
[prev in list] [next in list] [prev in thread] [next in thread]