Re: Expect 100-continue

A summary of a talk with Yves Lafon:

------
If the client implements HTTP/1.1 and can handle the Expect:100, it 
should always use it, regardless of how much data is being sent in the body.
This will always save bytes sent on the net.
-----

I agree that there are some broken servers and clients out there
that don't know how to handle the Expect: 100 header. For these, you
need to have a workaround and also mail a bug report complaining about
their implementation. But it should be clear to the developer that
this is a workaround and not the way that the HTTP/1.1 spec recommends to do 
so, so that he doesn't use that workaround systematically, even with
servers that do understand the Expect: header.

-jose

On Tue, Mar 12, 2002 at 07:37:56PM +0100, Manuele Kirsch Pinheiro wrote:
> 
> I known, I risk to create a big discussion, but... ;)
> I would like to known everybody's opinion about a small detail about 
> "Expect : 100-continue". Is this header mandatory when we are sending 
> any kind of message body?
> It's claire for me that, when we are using POST and PUT methods, this 
> header is very useful. But, and the rest? For example, the new methods 
> proposed by WebDAV? I didn't use it in my webdav module. In fact, I used 
> the message body suggestion from Josh Watt, Xinju Wang and Steinar Bang 
> discussion (by the way, Thank you all! :)).  But, in a off-line 
> discussion, somebody ask me about that.. I search in HTTP/1.1 
> specification (RFC2616) and in WebDAV (RFC2518), and I found anything 
> that indicates that "Expect: 100-continue"  header is mandatory when 
> sending a body. Even more, RFC2518 don't do any mention to it.. So, I 
> think that is not mandatory, but just a question of "common sense". A 
> client developper may decide when it is necessary and when it is useful 
> and when it must be used.. What you (everybody) think about it?  Should 
> we use always "Expect: 100-continue" header when sending any body, even 
> small xml bodies?

Received on Thursday, 14 March 2002 13:37:48 UTC