Re: Content negotiation for request bodies

Brian Smith wrote:
>> The problem with Expects, is it's only specified in HTTP 1.1, and 
>> every link in the chain must support it for it to work.  In the 
>> special case of
>> Expects: 100-continue, this has grave problems with proxies that I've 
>> raised before, and a heuristic timeout waiting for a 100-continue 
>> which may never arrive causes further problems.
> 
> There is a lot of software generating "Expect: 100-continue" now. In particular, the .NET client libraries seem to add this by default. Curl uses it by default. Apache supports it well. If there is any problem, it would seem to lie in with proxies. Is "Expect: 100-continue" really that problematic for commonly deployed proxies?
> ...

One problem is that server framework implementations (such as servlet 
implementations) frequently answer with "100 Continue", without actually 
doing what RCF2616 says they should do:

"The purpose of the 100 (Continue) status (see Section 10.1.1) is to 
allow a client that is sending a request message with a request body to 
determine if the origin server is willing to accept the request (based 
on the request headers) before the client sends the request body. In 
some cases, it might either be inappropriate or highly inefficient for 
the client to send the body if the server will reject the message 
without looking at the body." -- 
<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.8.2.3>

Today servlet containers just say "100 Continue" without actually 
consulting the servlet. That defeats part of what it's for.

There have been proposals around for many years to improve this, but as 
far as I know, nothing has happened so far.

BR, Julian

Received on Tuesday, 26 February 2008 21:38:44 UTC