RE: More issue resolution: OVERLAP_5.3_AND_8.7.2, XML_LANG_CLARIFY, COPY_LIVE_PROPS

> 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:39 AM
> To: 'Julian Reschke'; 'Jason Crawford'; 'Webdav WG'
> Subject: RE: More issue resolution: OVERLAP_5.3_AND_8.7.2,
> XML_LANG_CLARIFY, COPY_LIVE_PROPS
> 
> 
> 
> 
> > This currently says:
> > 
> > "When the 302 and 303 status codes are returned as the only 
> > status code for a response, HTTP1.1 uses the Location 
> > response header to indicate where the client should make the 
> > request.  The Multi-Status response syntax does not allow for 
> > the Location header information to be included in an 
> > unambiguous way, so servers MAY choose not to use these 
> > status codes in Multi-Status responses. If a clients receives 
> > this status code in Multi-Status, the client MAY reissue the 
> > request to the individual resource, so that the server can 
> > issue a response with a Location header for each resource."
> > 
> > What's the rationale for allowing servers not to return 3xx 
> > response status in multistatus? And what should they return 
> > *instead*? I think this needs more discussion...
> > 
> 
> The server *can* return 3xx response status in multi-status, or 
> it can try to avoid that.  This paragraph attempts to do two things:
>  - to suggest to the server implementor that 3xx response codes 
> are somewhat problematic in Multi-Status.  Since I'm not entirely 
> sure what 3xx response codes in Multi-Status would accomplish or 
> why they would be used, it's hard to say whether it's possible to 
> choose 3xx or some other error code that doesn't take a Location 
> header.  We'd have to discuss specific scenarios.
>  - to suggest to the client implementor how a 3xx response code 
> in a Multi-Status can be dealt with in the existing set of functionality.

The issue that I see here is that this is a *change* to RFC2518 that will make a subsequent WebDAV redirect ref spec harder than it needs to be.

PROPFIND on a collection is specific way to marshall information about it's internal members. Unless explicitly otherwise stated, it should faithfully reproduce what I'd get if I did a HEAD request on the internal member.

Thus, return a 2xx status in PROPFIND although a HEAD on the resource will return a 3xx is inconsistent and will make it harder for redirect-aware clients to distinguish between "simple" resources and redirects (when browsing collections via PROPFIND).

This paragraph only affects servers that both support redirects *and* make them visible through WebDAV. As far as I know, there's only one implementation doing this (ours), and we certainly would prefer that clients can rely on getting the 3xx status codes (instead of leaving that to the server).

> I'm currently happy with this because it ought to improve 
> interoperability without making any new requirements or defining 
> any new syntax -- it explains how it's possible already.  But 
> everything is of course up for discussion, which is what we're 
> doing.  This was first published back in March, FWIW.
> 
> I can't find exactly where I got this suggestion, but I think it 
> may have been from you, Julian.  This change went into RFC2518bis 
> after our in-person interim meeting at Apple early this year.  
> The notes for that meeting said that you were going to suggest 
> language for this.
> 
> http://www.sharemation.com/~milele/public/dav/minutes/wg-notes-jan-2003.
> txt

I honestly don't remember. However it's true thatg I volunteered to propose marshalling for the Location information, and I'll try to do that ASAP.

Julian

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

Received on Thursday, 26 June 2003 07:19:31 UTC