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

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/ ?

>
> 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.

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().

AYJ

Received on Friday, 20 July 2012 02:19:54 UTC