- From: Jim Whitehead <ejw@cse.ucsc.edu>
- Date: Thu, 21 Jun 2001 15:23:00 -0700
- To: "WebDAV WG" <w3c-dist-auth@w3.org>
Accidentally caught by the spam filter. I've added Joe's btconnect.com address to the accept2 filter. - Jim -----Original Message----- From: Joe Orton [mailto:jorton@btconnect.com] Sent: Thursday, June 21, 2001 3:20 PM To: Webdav WG Subject: [Moderator Action] Re: Obscure HTTP 1.1 header of the day... On Thu, Jun 21, 2001 at 02:37:13PM -0700, Lisa Dusseault wrote: > RFC2616 defines the Expect: header for _any_ request method that normally > takes a body. > > Before today, I thought the Expect: header was just the client's way of > advertising client support for the 100-Continue response. (I've never seen > it sent by a client, BTW.) > > But RFC2616 says "The Expect request-header field is used to indicate that > particular server behaviors are required by the client." This is ambiguous, > but clearly the intention is that the server has some responsibility here > and can't safely ignore the Expect header. Early version of my clients used "Expect: 100-continue" by default for large request bodies. Problem is that if the next-hop server *doesn't* support the feature, you end up with a hung connection as both sides block waiting for the other, forcing the client to implement a "timeout" waiting for the interim 100 response/error. (that's all covered in RFC2616) So if you turn this on by default you face the client "hanging" for X seconds until the timeout kicks in, if there is an HTTP/1.0 proxy in the way and you didn't know about it, or the HTTP/1.1 server doesn't support this correctly. I turned it off in the end to prevent it causing weird interop problems. > Unless RFC 2518 were to explicitly state that methods defined there did not > use the Expect header... Then WebDAV implementors would only have to worry > about implementing it correctly for PUT and POST. Hmm? Not sure what you mean there - RFC2616 defines this behaviour, so, if a DAV server claims HTTP/1.1 compliance the header must be honoured regardless of method. Regards, joe
Received on Thursday, 21 June 2001 18:25:18 UTC