Subject: Issues: MKCOL_AND_302, IMPLIED_LWS, PUT_AND_INTERMEDIATE_COLLECTIONS, INTEROP_DELETE_AND_MULTISTATUS

From: "Lisa Dusseault" <[email-masked]>
Date: Sun, 22 Jun 2003 12:35:18 -0700

MKCOL_AND_302: This issue can be marked "inBis" if not CLOSED.  Draft -03 says that MKCOL can return 302 and there have been no objections so far.

IMPLIED_LWS: This issue can be marked "inBis" if not CLOSED.  Draft -03 says that the HTTP rules are imported "including the rules about implied linear white-space."

PUT_AND_INTERMEDIATE_COLLECTIONS: This issue can be marked "inBis" if not CLOSED.  Draft -03 says "The server MUST NOT create those intermediate collections automatically.”

INTEROP_DELETE_AND_MULTISTATUS: This is the old issue respecting how HTTP clients might be confused by a 207 response to a DELETE message, believing it to be a success message  <http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0062.html>.  Have we got consensus to continue using 207, on the basis that by now it would break far more WebDAV clients to *stop* using 207?

- Julian says continue using 207 but has also proposed switching to a 4XX
  <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/0049.html>
  <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/0065.html>
- Roy argues it violates RFC2616  
  <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/0046.html> 
- My vote is to continue using 207
  <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/0044.html>
- The interim meeting attendees in Jan 2003 were unanimous in continuing with 207
  <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/0044.html>
- John DeSoi points out that Netscape uses DELETE and 2XX should not be redefined
  <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/0057.html>
- Bob Denny says let's not violate RFC2616
  <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/0048.html>
- Geoff Clemm might want to clarify his position
  <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/0065.html>

I don't think we have consensus yet overall.  Please discuss, clarify, or even simply restate your position.

Lisa

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 23 Jun 2003 13:30:11 +0200

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Lisa Dusseault
> Sent: Sunday, June 22, 2003 9:35 PM
> To: Jason Crawford; 'Webdav WG'
> Subject: Issues: MKCOL_AND_302, IMPLIED_LWS,
> PUT_AND_INTERMEDIATE_COLLECTIONS, INTEROP_DELETE_AND_MULTISTATUS
> 
> 
> 
> 
> 
> MKCOL_AND_302: This issue can be marked "inBis" if not CLOSED.  
> Draft -03 says that MKCOL can return 302 and there have been no 
> objections so far.

It doesn't say anything specific about MKCOL and redirects. Or am I missing something?

Speaking of which: section 12.1 talks only about 302 and 303 in Multistatus. It should talk about all 3xx codes, in particular 301.

> IMPLIED_LWS: This issue can be marked "inBis" if not CLOSED.  
> Draft -03 says that the HTTP rules are imported "including the 
> rules about implied linear white-space."

Agreed.

> PUT_AND_INTERMEDIATE_COLLECTIONS: This issue can be marked 
> "inBis" if not CLOSED.  Draft -03 says "The server MUST NOT 
> create those intermediate collections automatically.”

Agreed.
 
> INTEROP_DELETE_AND_MULTISTATUS: This is the old issue respecting 
> how HTTP clients might be confused by a 207 response to a DELETE 
> message, believing it to be a success message  
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0062
> .html>.  Have we got consensus to continue using 207, on the 
> basis that by now it would break far more WebDAV clients to 
> *stop* using 207?
> 
> I don't think we have consensus yet overall.  Please discuss, 
> clarify, or even simply restate your position.

I think Roy has made a very good point about clients that do DELETE and are not aware of 207 being a valid (error) code for DELETE. Thus my proposal is not to use 207 when the operation did not entirely succeed, but instead use a 4xx code (keeping the multistatus response body). I think at this point there are only few clients which will actually properly process a 207 on DELETE, and those can probably easily upgraded.

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Geoffrey M Clemm <[email-masked]>
Date: Mon, 23 Jun 2003 08:20:39 -0400

The resolutions on the first 3 issues are fine with me.  WRT to
INTEROP_DELETE_AND_MULTISTATUS, my position was that a partial delete
is better classified as a "failure" (i.e. a new 4xx code), so unless
we identified a client that really depended on a 207 response from
DELETE, I'd be in favor of making this change (i.e. introducing a
4xx code that means "partial failure", and whose body is the same
DAV:multistatus currently found in a 207).

Cheers,
Geoff 

Lisa wrote on 06/22/2003 03:35:18 PM:

> IMPLIED_LWS: This issue can be marked "inBis" if not CLOSED.  Draft 
> -03 says that the HTTP rules are imported "including the rules about
> implied linear white-space."
> 
> PUT_AND_INTERMEDIATE_COLLECTIONS: This issue can be marked "inBis" 
> if not CLOSED.  Draft -03 says "The server MUST NOT create those 
> intermediate collections automatically.”
> 
> INTEROP_DELETE_AND_MULTISTATUS: This is the old issue respecting how
> HTTP clients might be confused by a 207 response to a DELETE 
> message, believing it to be a success message  <http://lists.w3.
> org/Archives/Public/w3c-dist-auth/1999AprJun/0062.html>.  Have we 
> got consensus to continue using 207, on the basis that by now it 
> would break far more WebDAV clients to *stop* using 207?
>

---

From: "Lisa Dusseault" <[email-masked]>
Date: Wed, 25 Jun 2003 17:46:35 -0700

> Or am I missing something?

Well it says 
"11.2	302 Found
   Any WebDAV request may be redirected using this status code." 

> 
> Speaking of which: section 12.1 talks only about 302 and 303 
> in Multistatus. It should talk about all 3xx codes, in particular 301.

Let's check 2616
 - 201 can use the Location header
   Although in WebDAV a MOVE or COPY may create new resources, currently
   the spec says that the server should not return 201 in Multi-Status for
   these methods.  Is that sufficient reason not to mention 201?  If you
   think something should be added here, please tell me what.
 - 300-303, 305, 307 all use the Location header
   I'm happy to mention all of these.

Lisa

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 26 Jun 2003 12:54:53 +0200

> Sent: Thursday, June 26, 2003 2:47 AM
> To: 'Julian Reschke'; 'Webdav WG'
> Subject: RE: Issues: MKCOL_AND_302, IMPLIED_LWS,

Yes, but the issue was:

"The specification is ambiguous on the handling of 302 by MKCOL.  It should explicitly state that MKCOL is redirected by a 302."

...so I was looking for something specific to 302. However I'm happy to resolve this by saying hat 302 considerations apply to *all* methods.

This being said: I'm not sure that I understand the original issue. An MKCOL request can possibly return a 3xx if and only if the request URI identifies an existing redirect ref resource -- in which case RFC2518 says that it should be a 405:

"405 (Method Not Allowed) - MKCOL can only be executed on a deleted/non-existent resource."

>    I'm happy to mention all of these.

I think the difference here is that PROPFIND was developed as a container for multiple HEAD results (at least this is my understanding). HEAD will never return 201, so therefore hardwiring all success codes (2xx) to "200" is defensable. So yes, 12.1 should say that multistatus can use all 3xx codes.

Julian