Re: 100 Continue and Expects

David Morris wrote:
> 
> 
> On Sat, 27 Mar 2010, Greg Wilkins wrote:
> 
>> 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.
>>
> ...
>> 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
> 
> I don't think so ... the server MUST be prepared to deal with the
> unexpected input ... could be a connection reset ... I don't think
> it is our place to dictate error handling. 

David,

I'm not sure what you are saying here, as this is not really error
handling.   In the circumstances I'm describing, the spec
allows a client to either not send the body (because it never
got a 100 continues) or it can send a body (because it didn't
delay an unreasonable time).

But the spec is not clear on how the server should handle
the later case, when the server is actually a RFC2616 compliant
server.


> A new MUST also isn't possible as that would change the protocol.

Oops I admit I've not read the bis charter, so I didn't know that
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.


cheers

Received on Saturday, 27 March 2010 21:24:24 UTC