Re: 100 Continue and Expects

Hi,

I'd like to wake up the discussion about 100 Continues in the specification.

In my experience with the Jetty server, one of the main users of Expect
continues is .net clients doing webservices.   Unfortunately there appears
to be a some clients that although they send expect 100 continues, they
always send the body regardless if the server has sent 100 continues
or not.

This behaviour is kind of allowed by RFC2616 as it says:

  "Because of the presence of older implementations, the protocol allows
  ambiguous situations in which a client may send "Expect: 100- continue"
  without receiving either a 417 (Expectation Failed) status or a 100
  (Continue) status. Therefore, when a client sends this header field
  to an origin server (possibly via a proxy) from which it has never
  seen a 100 (Continue) status, the client SHOULD NOT wait for an
  indefinite period before sending the request body"

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 spec allows container to not-send a 100 continues if there
is already content available to be read:

  "  - An origin server MAY omit a 100 (Continue) response if it has
        already received some or all of the request body for the
        corresponding request."

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

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.

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


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


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.


cheers

Received on Saturday, 27 March 2010 17:25:04 UTC