Re: 100 Continue and Expects

Jamie,

thanks for that info.  I had not realized that the client had
not choice but to not reuse the connection if a non-100 response
is received.

Then perhaps the bis spec can enhanced to make this point clearer.

It might also be good to suggest that servers send Connection: close
with non 100 responses if expect 100 is received.  This would
make clients that don't know they should close, do the close.

cheers


Jamie Lokier wrote:
> 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 04:21:14 UTC