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

From: Julian Reschke <[email-masked]>
Date: Thu, 02 Mar 2006 09:12:03 +0100

Hi,

while working on the revision of RFC2518 (WebDAV), the WebDAV working 
group came to the conclusion that what HTTP says about returning ETag 
headers in write operations (such as PUT) is insufficient.

Jim's draft summarizes the various issues and also contains some 
thoughts about what to do, from which we'd like to start a discussion on 
  the HTTP mailing list (<mailto:[email-masked]>).

Feedback appreciated,

Julian

[email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title		: Design Considerations for State Identifiers in HTTP and WebDAV
> 	Author(s)	: J. Whitehead
> 	Filename	: draft-whitehead-http-etag-00.txt
> 	Pages		: 13
> 	Date		: 2006-3-1
> 	
>    This document discusses design considerations for state identifiers
>    in the Hypertext Transfer Protocol (HTTP) and related protocols such
>    as WebDAV.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-whitehead-http-etag-00.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [email-masked] with the word unsubscribe in the body of the message.  
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
> 
> 
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-whitehead-http-etag-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-whitehead-http-etag-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce

---

From: Larry Masinter <[email-masked]>
Date: Thu, 02 Mar 2006 15:18:20 -0800

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

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.

Larry
-- 
http://larry.masinter.net

---

From: Martin Duerst <[email-masked]>
Date: Fri, 03 Mar 2006 11:19:24 +0900

A very tiny adjustment below. But since HTTP (RFC 2616) is still
at Draft Standard, couldn't this kind of clarification be added
in when going to Standard? Or is that the plan?

 >   assume that the data was stored exactly as sent.

I think that should read "If a strong ETag is returned, then the client can
assume that the data will subsequently be served exactly as sent."

How the data is stored is purely the server's business
(and (c) uses the right language).

Regards,    Martin.