RE: i107

On tor, 2008-07-31 at 12:14 -0500, Brian Smith wrote:

> I assume by "the resource" you mean the resource at the original request
> URI, not the resource at the Content-Location URI.

Content-Location IS the specific URI to this resource. Or if you like
the non-negotiated direct access URI to a specific variant of a
resource.

> RFC 2616 doesn't say that the client may delete any of the variants of
> http://example.org/foo.html by sending a DELETE request to
> http://example.com/foo.html.

To me it's exacly what it says. Quote from p3 6.7 Content-Location:

   The Content-Location value is not a replacement for the original
   requested URI; it is only a statement of the location of the resource
   corresponding to this particular entity at the time of the request.

   Future requests MAY specify the Content-Location URI as the request-
   URI if the desire is to identify the source of that particular
   entity.

> an extension to HTTP. In any case, there may be more than one variant of the
> resource at the Content-Location URI, so Content-Location doesn't even
> address a specific variant of *any* resource. 

No. The Content-Location URI is not supposed to be a negotiated
resource. If it is then the server implementation is wrong.

If the server can not provide unique URIs to each variant then no
Content-Location should be returned.

> It is unrealistic to assume that we never PUT to negotiated resources
> because many (on some servers, all) resources are negotiated as  "Vary:
> Accept-Encoding" at least.

Indeed. The catch is that implementations of dynamic content-encoding
hasn't really followed the entity variant model of HTTP that well.. so
the Content-Location model fails for such setups. And clients have to
work around it by not using Accept-Encoding if they want to be able to
update the resource.

> To refuse to define what happens when one
> requests a PUT (or DELETE) on content-negotiated resources effectively makes
> PUT and DELETE undefined for extremely common uses.

Not really.

> If a server changes (or
> deletes) the uncompressed variant of the resource upon a PUT (or delete) but
> leaves the compressed variant as-is, then I would say that server is
> definitely wrong, unless there is some explicit indicator in the request
> that says that only some specific variants are to be modified. But, HTTP
> doesn't provide any such indicator.

Try it and you will find it's exacly what servers using separate storage
for both the compressed and identity encoded variants is doing. But in
such setups you often MUST use the Content-Location URIs on updates or
negotiation will get disabled for the resource.

If you think of Content-Language then it makes more sense.

 Content-Encoding is a bit of a special case here and not a good
Content-* header to base any reasoning on, especially not considering
how it's most commonly implemented..

Regards
Henrik

Received on Thursday, 31 July 2008 20:13:52 UTC