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

On 20/07/2012 6:02 p.m., Willy Tarreau wrote:
> On Fri, Jul 20, 2012 at 12:32:11AM +0000, Osama Mazahir wrote:
>>> 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.
> But it does not cover the client which immediately receives the 417 and
> which refrains from sending and instead reuses the connection.

Did you mean the tricky case where encoding is attempted and the 417 
returns. For chunked the server does not support detecting a zero-length 
chunk as an aborted entity. But the client requires it to keep-alive. So 
the option there is client closure if it arrives late and server 
required to assume the next bytes after header are a new header set.
   Note that a zero-length chunk is "0CRLF" which is not a valid HTTP 
request-line even when assuming HTTP/0.9 compatibility. The other 
transfer encodings result in binary data which is also not valid 
request-method. The server aborting the connection on invalid 
next-request seems to take effect in that case regardless of encoding.

When the race is lost the server barfs and closes. When the race is won 
the client goes right to next request and the keep-alive works fine.

The key though is for the client to *always* continue with the attempted 
operation on a timeout. If the server does not reject it fast enough too 
bad.

Could we mandate a minimum client timeout suitable for slow high latency 
connections. Or suggest that it is linked to RTT somehow? as you say it 
is RTT related race, making a timeout depend on RTT seams reasonable if 
possible.

> It is all a matter of race condition : depending on the RTT between the
> client and the server, the exact same sequence of operations at both sides
> may lead to a different behaviour :
>    - only headers are sent, client does not send body and goes on with next
>      request ;
>    - body starts to be sent and server has to drain it.
>
> So the server cannot detect whether what follows is a body or a next
> request.
>
> I suspect that sending request-looking data in a POST with an Expect
> header might produce interesting results which merit being studied on
> various products :
>
>     POST /public HTTP/1.1
>     Host: www.example.com
>     Expect: 100-Continue
>     Content-Length: 100
>
>     GET /private HTTP/1.1
>     Host: www.example.com

In the above example the use of content-length requires that the server 
drain 100 bytes regardless of what the client does.

> In my opinion the only way to remain safe would be to systematically
> close the connection after a 4xx. However it could cause problems with
> connection-based authentication such as NTLM. It does not look like a
> trivial problem.

On NTLM the initial www-auth scheme advertisement can safely be closed. 
It's inefficient but safe.
The first handshake responses is where trouble comes in, and by that 
time the client should have stopped attempting Expect.


Amos

Received on Friday, 20 July 2012 07:29:27 UTC