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

From: "Hall, Shaun" <[email-masked]>
Date: Fri, 22 Jun 2001 09:35:55 +0100

Bits snipped

> -----Original Message-----
> From: Lisa Dusseault [mailto:[email-masked]]
> Sent: 21 June 2001 22:37
> To: Webdav WG
> Subject: Obscure HTTP 1.1 header of the day...
> 
> RFC2616 defines the Expect: header for _any_ request method 
> that normally
> takes a body.
> 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.

Thats how we understood 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.

Er not to be too picky, but according to my interpretation, you cannot have
a "Depth" header with PROPPATCH. Sec 9.2 states Depth header is only
supported if a method explicitly provides support for it. Sec 8.2.x
PROPPATCH doesn't mention Depth header at all. Server should return 400 (as
per sec 9.2). If you removed Depth header from above example, server would
only check /~lisa but no descendants.

Am I wrong ?

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

One interpretation is that any WebDAV method that takes a body should handle
the Expect header i.e. COPY, MOVE, LOCK, PUT, POST, PROPPATCH, PROPFIND (and
MKCOL if server supported body). Granted some of these methods take XML as
the body, but the server could perform some checks before it needed the XML
and thus return a response. This meets RFC 2616 sec 8.2.3 "a server is
willing to accept the request based on the request headers" and sec 10.1.1
"the initial part of the request has been received and has not been rejected
by the server". Obviously, if the client submitted the XML after it received
a 100, and the XML was invalid etc, the server could then send a 400 or
whatever is appropriate.

What do people think ?

> lisa

Regards

Shaun Hall
Xerox Europe

---

From: Joe Orton <[email-masked]>
Date: Fri, 22 Jun 2001 09:55:40 +0100

On Fri, Jun 22, 2001 at 09:35:55AM +0100, Hall, Shaun wrote:
...
> MKCOL if server supported body).

As I said already - if a server claims HTTP/1.1 compliance, it is a MUST
requirement that the server supports the Expect: 100-continue
functionality, regardless of method used.  RFC2616 is quite clear about
how origin servers should behave in section 8.2.3, and WebDAV doesn't
affect that in any way or allow alternate interpretation.

> Granted some of these methods take XML as

Sure, I thought the best motiviation to use 100-continue in a DAV client
was to prevent having to send a large request body with a PUT twice in
the presence of authentication.

i.e. PUT (expecting 100-continue) -> if authentication is required, the
401 response comes straight away before having to upload x mb to the
server.

Regards,

joe