New (minor) issue for RFC-2518: revising wording in section 8.3

RFC-2518 currently states in section 8.3:

   The MKCOL method is used to create a new collection. All DAV
   compliant resources MUST support the MKCOL method.

But then section 8.3.1 goes on to say:

   If the resource identified by the Request-URI is
   non-null then the MKCOL MUST fail. 

I believe the second sentence of 8.3 should be changed to read:
"All DAV compliant null and lock-null resources MUST support
the MKCOL method".  Since any other WebDAV resource is
required to fail the MKCOL request, it seems rather bogus
to require them to "support" it.  In particular, this
requirement damages any attempt by a client to populate its GUI with
whether or not a MKCOL operation is appropriate
for a given resource.

Cheers,
Geoff


-----Original Message-----
From: Joe Orton [mailto:jorton@btconnect.com]
Sent: Friday, June 22, 2001 4:56 AM
To: Webdav WG
Subject: Re: Obscure HTTP 1.1 header of the day...


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

Regards,

joe

Received on Monday, 25 June 2001 08:48:15 UTC