Re: Obscure HTTP 1.1 header of the day...

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