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

From: "Lisa Dusseault" <[email-masked]>
Date: Thu, 21 Jun 2001 14:37:13 -0700

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.

Krishnamurthy and Rexford, in "Web Protocols and Practice", give a cool
example of how they think it's used with the "100-Continue" value.  The
client sends a request that normally has a body, but sends the Expect header
instead of the body.  The server indicates with 100-Continue that the client
should proceed with the request if it's likely to succeed, and the client
sends the body in the second message.  But if the request is going to fail,
the server responds with an error instead.

E.g.
	POST /foo/bar HTTP/1.1
	Content-Length: 23248
	Expect: 100-Continue

The server would respond with an error of some kind if it doesn't have
/foo/bar location, if /foo/bar doesn't allow POST, if the Content-Length is
too long, or anything else.

If anybody's got any other expectation of how the header is supposed to
work, I'd love to hear it.

Now how it affects WebDAV... RFC2518 makes no mention of the Expect header,
but RFC2518 servers are expected to be compliant HTTP 1.1 servers. This
would presumably mean they must support the Expect header.  So if I sent a
server the following request:
	PROPPATCH /~lisa HTTP/1.1
	Content-Length: 1234
	Depth: infinity
	Content-Type: text/xml
	Expect: 100-Continue

The server should NOT wait for a body on this request, and it should respond
with 100 Continue if it's going to allow me to do the PROPPATCH based on the
information provided.  E.g. it tests to see if I have write permission on
/~lisa and all its descendants.

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?

lisa

---

From: "Jim Whitehead" <[email-masked]>
Date: Thu, 21 Jun 2001 15:23:00 -0700

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:[email-masked]]
Sent: Thursday, June 21, 2001 3:20 PM
To: Webdav WG
Subject: [Moderator Action] Re: Obscure HTTP 1.1 header of the day...

> 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.

> 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