W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2003

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 26 Jun 2003 13:19:23 +0200
To: "Lisa Dusseault" <lisa@xythos.com>, "'Julian Reschke'" <julian.reschke@gmx.de>, "'Jason Crawford'" <ccjason@us.ibm.com>, "'Webdav WG'" <w3c-dist-auth@w3c.org>
Message-ID: <JIEGINCHMLABHJBIGKBCIENBHKAA.julian.reschke@gmx.de>

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


<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 
Received on Thursday, 26 June 2003 07:19:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:29 UTC