Re: remaining redirect ref issues

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

I am certain I have said this before, though it was several years ago.
The RESOURCE IS NOT A STORAGE ITEM ON THE SERVER!  Failure to get 
straight
on that one bit is what causes webdav to trip over HTTP whenever it
tries to "author" anything other than a boring old file.

In this case, there must be two different URIs -- one for the resource
and one for the configuration of that resource.  That configuration
may be as simple as a URI, maybe a status code and a URI, or maybe even
an XML document -- that is what must be defined by the redirect 
protocol.
The actual URI which responds to requests with a redirect should have a
link to its configuration URI, such that an authoring tool can discover
the authorable resource that causes this resource to redirect.  That is
why webdav requires a source link in order to perform HTTP authoring.

The same principle holds for all dynamic content.

....Roy

Received on Wednesday, 12 November 2003 16:08:48 UTC