Re: 100 Continue and Expects

lör 2010-03-27 klockan 10:24 -0700 skrev Greg Wilkins:

> The issue with this, is what happens if the server does not
> send a 100 continues on the very first request it receives
> from a client with the Expect: 100 header.

The server should send an 100 Continue when it accepts to receive the
body. Exception being if part of the body has already received by the
server.

> The spec allows container to not-send a 100 continues if there
> is already content available to be read:

Yes as it then knows the client is no longer waiting for 100 Continue.

> This is fine if the container wants to read and handle that content.

Irrelevant.

> However, the case that is not covered by the spec, is what if
> the server does not want to read the body (eg it wants to send
> a 401 or 302), but there is already content available to be read.

That case is the same as when there is no Expect: 100-continue. The
server then responds with the final status, and eats the request body if
it wants to keep the connection persistent. Or if it wants to close the
connection then waits until the response data has been ACK:ed at the TCP
level plus some more to give the client some chance to pick up the
response before connection is closed.

The last part is one of the reasons why 100 Continue was added, adding
structure in how servers can reject request bodies by closing the
connection in controlled manners.

But it's true the wording in RFC2616 leaves much of the detail out or
hides it scattered over many different and seemingly unrelated sections.

> It should not be possible for this content to be a pipelined
> request - as using pipelining with expect 100 cannot possibly
> work (and maybe spec should explicitly say they can't be used
> together).    So the data must be the body of the request
> that was sent regardless by the client (maybe after NOT
> waiting for an indefinite period).

Correct.

> So it would be great if the spec could give guidance to
> tell servers what to do with data that is received
> before any response is sent to an expect 100 continues.
> 
> Perhaps something like:
> 
>     An origin server MUST read the request body if it has
>         already received some or all of the request body for the
>         corresponding request before sending any response

No.

> There is still an implicit race here... but if clients are
> going to send bodies regardless of the 100 continue mechanisms
> then servers need to be able to read those bodies regardless
> as well.

>From 100 Continue server requirements:

server handling of request with 100-continue expectation:

        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.

server handling when there is no such expectation:

 request includes a request body, and the server responds
        with a final status code before reading the entire request body
        from the transport connection, then the server SHOULD NOT close
        the transport connection until it has read the entire request,
        or until the client closes the connection.


The race window you worry about is covered in the section following this
"Client Behavior if Server Prematurely Closes Connection", which
squarely puts the burden on the client if it's not being careful when
sending request bodies..

But in real-life and experience servers need to be careful as well, and
is reflected in some other sections of the specifications requiring
servers to perform a graceful close and/or wait for TCP ACK of the
response data.

Regards
Henrik

Received on Sunday, 28 March 2010 19:17:06 UTC