Re: remaining redirect ref issues

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 UTC