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

> 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.
>
> That's an interesting case. I don't know how haproxy handles 
> it, I suspect it could be tricky.

I think the current state is fine.  The current text says "If it responds with a final status code, it MAY close the transport connection or it MAY continue to read and discard the rest of the request."  Windows tries to leave the connection open (i.e. of course, upper layer can always override or we may have hit an non-continuable error such as corrupted request).  This allows the server to handle the following cases:
1) Client sent the entity-body before getting the expect-answer (e.g. timeout).
2) Client believes it is more efficient to send irrelevant entity-body instead of tearing down and warming up a new connection.
3) Client was sending a chunked entity-body and can gracefully indicate request end with a zero chunk.

-----Original Message-----
From: Willy Tarreau [mailto:w@1wt.eu] 
Sent: Wednesday, July 18, 2012 3:09 PM
To: Osama Mazahir
Cc: Roberto Peon; Julian Reschke; Gabriel Montenegro; Adrien de Croy; Poul-Henning Kamp; Amos Jeffries; ietf-http-wg@w3.org
Subject: Re: usability of 100-continue, was: HTTP2 Expression of Interest : Squid

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.

That's an interesting case. I don't know how haproxy handles it, I suspect it could be tricky.

Regards,
Willy

Received on Friday, 20 July 2012 00:32:48 UTC