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

From: "Clemm, Geoff" <[email-masked]>
Date: Mon, 25 Jun 2001 08:53:54 -0400

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:[email-masked]]
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

---

From: Alan Kent <[email-masked]>
Date: Tue, 26 Jun 2001 11:48:33 +1000

>    compliant resources MUST support the MKCOL method.

What does this really mean? Does a resource support MKCOL? Is MKCOL
"applied" to the parent collection? The URI is the new collection
resource to be created isn't it? If I have a non-collection resource
(eg a web page /foo.html), is it mandatory that I be able to do a
MKCOL /foo.html/newcoll?

> the MKCOL method".

I think I sort of agree with what you are saying, but isn't it more
that the MKCOL method is really being applied to either the parent
collection resource or a lock-null resource (if it exists for the new
collection URI)? I am not sure of the wording - my point is that not
all "null" resources need to support MKCOL.  And related, weren't
we trying to reword "null resources" as "unbound URIs" or something?

> Since any other WebDAV resource is

Bottom line: I agree with the concept, but I am not sure if the new

>    compliant resources MUST support the MKCOL method.

to

     The MKCOL method is used to create a new collection.
     If the URI is a DAV compliant lock-null resource, the resource
     MUST support the MKCOL method.
     All DAV compliant collection resources must also support
     MKCOL for creating new members for the collection.

Hmmm. Getting the wording right is hard isn't it?
Note: I am only reading what you have specified. I have not read
the surrounding text in the spec.

Alan