Re: usability of 100-continue, was: HTTP2 Expression of Interest : Squid

On 20/07/2012 6:08 p.m., Willy Tarreau wrote:
> On Fri, Jul 20, 2012 at 02:19:16PM +1200, Amos Jeffries wrote:
>> On 19/07/2012 10:09 a.m., Willy Tarreau wrote:
>>> On Tue, Jul 17, 2012 at 10:32:58PM +0000, Osama Mazahir wrote:
>>>> It's not broken as long as we are OK that the connection has to be closed
>>>> upon expectation rejection (for non-chunked entity-body).
>>>>
>>>> Based on my understanding, the client must close the connection if the
>>>> server
>>>> replied with a 4xx [1] against a non-chunked request.  Which makes sense
>>>> as
>>>> it ensures message integrity on a persistent connection [2].
>>>> Essentially, we
>>>> break the ambiguity by having the server assume that the next byte (after
>>>> the
>>>> CRLFCRLF) will be entity-body.
>>> You're right indeed, the protocol is broken in this case depending on
>>> whether
>>> the client gets the 4xx in time and refrains from sending the body, or if
>>> it
>>> starts sending the body before receiving the 4xx.
>>>
>>> The protocol does not allow us to tell what the server will get depending
>>> on
>>> the timing (either body or next request).
>>>
>>> I think we should state that upon 4xx in response to Expect: 100-Continue,
>>> the server should close the connection (after draining possibly pending
>>> data),
>>> just as it would do on a redirect to another domain for instance.
>> Why should a redirect to another domain have any relevance to the
>> connection state?  What if the client was a proxy which collated many
>> client requests for htp://example.com/, each of which needed redirecting
>> to http://example.net/ ?
> The proxy use-case is a valid one. Still, I've observed many times that
> some servers close the connection on redirects to external hosts. Now
> whether it's the application which adds a "connection: close" or the
> framework which does this for free, I don't know. The reason clearly is
> that the browser is not expected to reuse the connection when going away,
> which is not true at all when the client is a proxy, as you noted.

The key word in there is probably "browser", the assumption that each 
client is singular ("browser") and that each connection is singular 
("user") is very widespread.

That is no reason for any compliant server to disconnect. Let the broken 
servers do it, and let the correct servers gain the benefits of being 
correct.

Referring to this part specifically: "the server should close the 
connection (after draining possibly pending data), just as it would do 
on a redirect to another domain"


>>> That's an interesting case. I don't know how haproxy handles it, I suspect
>>> it could be tricky.
>> Always assume its the entity body when one is expected. Only listen to
>> explicit client signals that there is none. Such as a close(), last
>> bytes of content-length arriving, zero-chunk, or non-chunk.
> The issue is if the client is allowed to reuse the connection after it
> receives an 4xx without sending the body. So the examples you give are
> the ones that work well :-)
>
>> There are other players in the game as well. Transfer-Encoding gzip,
>> deflate, compress appear to contain no markers which would indicate end
>> of object to servers - yet being Transfer-Encoding they usually cannot
>> be accompanied by content-length. AFAICT the only reliable marker they
>> have is close().
>  From what I remember of my last reading of draft-19, it was clearly stated
> that if a transfer-encoding other than chunked is present, then chunked MUST
> be present last so the transfer is always chunk-encoded, precisely for this
> issue. You can send safely reject messages which contain Transfer-Encoding
> without "chunked" as the last one (you'd better recheck the spec than take
> my word for it though).

There is no mandate that chunked is *always* to be used with them 
though. Only that when combined the best is last.

We have had to take that assumption on our own guess at good-practice in 
Squid and decoded to always chunk 1.1 when content-length is missing. 
Regardless of other encodings.


Amos

Received on Friday, 20 July 2012 06:45:49 UTC