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

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