W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2001

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

From: Joe Orton <jorton@btconnect.com>
Date: Fri, 22 Jun 2001 09:55:40 +0100
To: Webdav WG <w3c-dist-auth@w3c.org>
Message-ID: <20010622095540.A20407@light.plus.com>
On Fri, Jun 22, 2001 at 09:35:55AM +0100, Hall, Shaun wrote:
> > 
> > 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).

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

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


Received on Friday, 22 June 2001 05:01:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:22 UTC