Re: 100 Continue and Expects

Greg Wilkins wrote:
> new MUSTs  are not possible.    However, I don't really think this
> is a change in the protocol, just some guidance on how to handle
> a little ambiguous corner.  A MAY or SHOULD would be equally
> helpful in reminding servers that clients may send bodies
> even if 100 is not sent.

The client may send a request body, or close the connection.  What it
can't do is omit the body and send another request on the same
connection.  That said, if it's sending chunked, the client could
truncate the body it's sending if it believes the server doesn't care
about the body, and then reuse the connection.  Because nobody does
chunked requests, though, I'd be hesitant about assuming it works.

I found the section in RFC2616 about the client not having to send the
request body when it receives an error a bit confusing, but after
asking this list a couple of years ago, it was clarified that the
client may send it or close the connection, but it can't simply not
send a body and reuse the connection for another request (unfortunately).

The only benefit of 100 Continue is that the client can read the
response and close, without saturating the link with an unused request
body.

  => RFC2616 does refer to an "error" response in this case, which
     is also a bit confusing - because this behaviour should be fine with
     *any* response code, and it's useful for 3xx.  Perhaps this could
     be relaxed in HTTPbis?

I did experiment with streaming a response at the same time as sending
the request body - which should be fine with the abort rule as long as
the server sends 100 Continue first - but found most clients and
servers didn't behave well with mutual streaming like this.  A few
were ok, which would have been a nice way to reduce connections for
some ajaxy/comety applications.

-- Jamie

Received on Sunday, 28 March 2010 00:32:00 UTC