RE: i107

Henrik Nordstrom wrote:
> tor 2008-07-31 klockan 08:24 -0500 skrev Brian Smith:
> 
> > In a thread earlier this year, we basically came to the conclusion 
> > that Content-Location is generally useless for anything 
> > except cache invalidation due to the possibility of spoofing.
> 
> I disagree.
> 
> You can't cache content across Request-URI and 
> Content-Location as being authorative for the 
> Content-Location URI, but it's fine to use the 
> Content-Location URI for updates and other modifications to 
> the resource.

I assume by "the resource" you mean the resource at the original request
URI, not the resource at the Content-Location URI. HTTP provides no
assurances that there is any useful relationship between the original
request URI and the resource referenced in the Content-Location URI. For
example:

   GET http://example.org/foo.html HTTP/1.1
   ...

   HTTP/1.1 200 OK
   Content-Location: http://example.com/foo.html

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. Doing so requires a leap of faith that is not
supported or encouraged by the specification. A protocol for that would be
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. 

> RFC2616 doesn't define how a PUT affects the server state at 
> all. But it is implicitly assumed you never do PUT to 
> negotiated resources and only non-negotiated resources and 
> that the request entity is normally stored as-is. The effects 
> of content negotiation on PUT requests is not explored at all 
> in the spec, except for Content-Location indicating the 
> actual resource URI of the created/modified resource.

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

Regards,
Brian

Received on Thursday, 31 July 2008 17:14:55 UTC