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: Lisa Dusseault <lisa@xythos.com>
Date: Wed, 25 Jun 2003 17:38:33 -0700
To: "'Julian Reschke'" <julian.reschke@gmx.de>, "'Jason Crawford'" <ccjason@us.ibm.com>, "'Webdav WG'" <w3c-dist-auth@w3c.org>
Message-ID: <006701c33b7b$462d5ca0$fdcb90c6@lisalap>

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

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.


Received on Wednesday, 25 June 2003 20:38:28 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:27 UTC