W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2006

Re: I-D ACTION:draft-whitehead-http-etag-00.txt

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 03 Mar 2006 17:03:23 +0100
Message-ID: <440868CB.5060308@gmx.de>
To: Larry Masinter <LMM@acm.org>
CC: 'HTTP Working Group' <ietf-http-wg@w3.org>

Larry Masinter wrote:
>> Jim's draft summarizes the various issues 
> Looking through this for the issues, this is what I come up with:
> It looks like the HTTP spec doesn't say enough about
> ETag headers in 200 and 204 responses to PUT. 
> And there is a question, when a HTTP server accepts a PUT
> but will modify the octet stream before a subsequent GET
> of whether it can return a strong ETag (presumably for
> the data it has, not for what was sent).
> But doing so wouldn’t be useful -- the client stored
> something, but gets back a strong etag for data that it
> doesn't have.

It still could be useful. For instance, a SCM server that does keyword 
expansion upon PUT could return strong ETags, and if the client would 
use that ETag in subsequent PUT (with If-Match request header), there 
wouldn't be a problem at all.

I think we should not rule out use cases like this one.

> So, I'd suggest a couple of things:
> (a) any server response for a successful PUT may contain
>  an ETag header (200 and 204 as well as 201).
> (b) If a strong ETag is returned, then the client can 
>    assume that the data was stored exactly as sent.
> (c) If the server modifies the data before storing it
>   in a way that it cannot guarantee a byte-for-byte
>   copy in a subsequent GET, it shouldn't use strong eTags.

That's a simple solution, but it doesn't cover many use cases where 
servers DO rewrite content, and clients still want ETags for authoring.

Best regards, Julian
Received on Friday, 3 March 2006 16:11:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:27 UTC