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

Re: remaining redirect ref issues

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 10 Nov 2003 15:29:49 +0100
Message-ID: <3FAFA0DD.7090102@gmx.de>
To: w3c-dist-auth@w3.org

Hi,

in case people want to discuss this during the IETF meeting, here's a 
summary of the major open issue left with the redirect references 
protocol 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-redirectref-protocol-latest.html>).

There are (at least) two major design goals, but unfortunately both are 
in direct contradiction:

#1: Maximum consistency with HTTP/1.1 (RFC2616). This means that any 
request that addresses a redirect reference resource MUST result in a 
3xx status code (obviously the whole point is that GET MUST result in a 
redirection, and if it does, it's hard to say why other methods such as 
PUT or DELETE should behave differently). Therefore, the redirect 
reference protocol introduces a new request header 
("Apply-To-Redirect-Ref") through which a client can indicate that the 
request indeed should be applied to the redirect reference resource itself.

#2: Maximum usability with existing clients. For instance, the Microsoft 
Webfolder client will not be able to DELETE a redirect reference 
resource unless the server deviates from #1.

Right now I'm not sure about the best way to resolve this. Currently the 
spec chooses #1 (back when this decision was made, there was probably 
the assumption that existing clients would quickly be updated -- 
something that probably isn't true today).

However this may result in implementers either just ignoring these 
rules, or adding special workarounds based on "User Agent" detection.

Feedback appreciated,

Julian


-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Monday, 10 November 2003 09:29:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:05 GMT