Re: i22: ETags on PUT responses

On mån, 2008-01-07 at 07:56 +0100, Julian Reschke wrote:
> Henrik Nordström wrote:
> > sön 2008-01-06 klockan 14:20 +0100 skrev Julian Reschke:
> >> Unlikely if the content was rewritten. A server can protect itself from 
> >> that by generating the strong etag in a manner that guarantees that a 
> >> range request will fail.
> > 
> > Which is pretty much the same as disabling Range request on the resource
> > entirely, as returning a different strong ETag on a GET request without
> > any modifications to the resource would be even more confusing and
> > damaging.
> 
> Would it? How?

Well, perhaps not damaging, but at least confusing.

For one thing intermediary caches will get confused on If-None-Match
requests, and either return a the transformed representation to the
client even if it hasn't really changed from what the client PUT, or
flush it's own cache if the request gets forwarded as the 304 response
indicates the object has changed compared to the cached representation
held in the intermediary cache.

It's no problem for chained authoring requests using PUT/DELETE/etc
however, only conditional If-None-Match cache validation GET requests.

> Note they are allowed in "If" headers (RFC4918).

True, but If is not in HTTP/1.1, and is more tailored for WebDAV than
general HTTP.

> Yes. We need to resolve all these issues (weak vs if-none-match, the 
> matching function, the "requested variant", Etag...) in a coherent way.

The "requested variant" is pretty clear. The variant returned had the
request been a GET request, or in case of the ETag returned by PUT a GET
request immediately after completion of the PUT.

And no, this do not fit entirely with WebDAV properties, but I am sorry,
that's a WebDAV fault, not HTTP.

It's also clear that PUT, DELETE etc is not designed to work with
negotiated resources, and is meant to be used on the individual resource
location (i.e. Content-Location of a negotiated resource). However, due
to security concerns Content-Location can never be considered to be a
substitute for the Request-URI except in cache invalidations even if
clients MAY use the Content-Location URI in future references to the
same variant or variant version depending on the server implementation.

But it's not obvious how to get this down in the correct wording..

It's also not clear how to handle ETag then a client makes a transition
from Request-URI to Content-Location URI for the purpose of authoring a
negotiated resource or similar.

Rgards
Henrik