Re: draft-whitehead-http-etag, Content-Location and 200 OK

Mark Nottingham wrote:
> 
> 
> On 2006/04/04, at 11:47 AM, Julian Reschke wrote:
>>
>> That would be correct, but "ETag" isn't an entity-header 
>> (<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.7.1>) but 
>> a Response Header 
>> (<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.6.2>).
> 
> Ah, my bad. Thought I'd checked that.
> ...

So, summarizing: I think we can state that RFC2616 already says that an 
Etag response header in PUT is for the *requested variant*, not the 
enclosed entity body. Thus, I'd like to rephrase my recommendation to say:

5.1.  Julian's suggestion

    This proposal is based on the assumptions below:

    o  Clients can not assume that servers do not rewrite content sent
       with PUT.

    o  Furthermore, clients can not assume that an ETag they may be
       getting in a PUT response can be used as cache validator in a
       subsequent GET.

    o  We don't want to break existing servers.

    o  Any extension we come up with should be as simple as possible,
       making it more likely to be implemented.

    Thus proposing the following extensions/clarifications:

    o  Clarify the language [RFC2616] about the meaning of ETag headers
       in 2xx responses, such as in <http://lists.w3.org/Archives/Public/
       ietf-http-wg/2006JanMar/0003.html>.

    o  Clarify that servers may return a new ETag for any method that may
       affect the requested variant (such as a PROPPATCH that rewrites
       the content of the resource).

    o  Optionally, add a new response header through which a server can
       indicate that it has indeed stored the submitted entity byte-by-
       byte (this is a simplified variant of Jim Whitehead's proposal
       that would give the client control about what kind of content
       rewriting is allowed).

Best regards, Julian

Received on Monday, 10 April 2006 15:36:02 UTC