Re: i22: ETags on PUT responses

Henrik Nordstrom wrote:
> ...
>> 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.

Understood; I just keep mentioning it because it's good enough for 
WebDAV clients (such as Werner's).

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

I'm totally happy with that clarification, but I think Roy was arguing 
differently.

> 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

Agreed. A server that supports authoring negotiated resources better 
supply URIs of non-negotiated resources through Content-Location.

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

Good point. That would require a new HTTP feature, right?

BR, Julian

Received on Monday, 7 January 2008 13:24:56 UTC