RE: Issues: MKCOL_AND_302, IMPLIED_LWS, PUT_AND_INTERMEDIATE_COLLECTIONS, INTEROP_DELETE_AND_MULTISTATUS

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Thursday, June 26, 2003 2:47 AM
> To: 'Julian Reschke'; 'Webdav WG'
> Subject: RE: 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?
> 
> Well it says 
> "11.2 302 Found
>    Any WebDAV request may be redirected using this status code." 

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

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

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


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

Received on Thursday, 26 June 2003 06:55:02 UTC