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

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.

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

Regards,
Willy

Received on Friday, 20 July 2012 06:09:22 UTC