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

Section 5 comments (Re: I-D ACTION:draft-whitehead-http-etag-00.txt)

From: Wilfredo Sánchez Vega <wsanchez@apple.com>
Date: Fri, 3 Mar 2006 12:29:26 -0800
Message-Id: <56D84AC4-137E-47B2-AF1E-E83A98AEA7F7@apple.com>
To: HTTP Working Group <ietf-http-wg@w3.org>

   And on section 5, I'm liking Jim's proposal.

   I'd rather say that a server may chose not to sent the *-State  
headers if they aren't specifically requested, but that they may  
chose to include them anyway if they wish to.  (I think Jim's trying  
to avoid forcing the server to compute something that may be  
expensive, not to restrict what a server can send to clients.)

   I think Content-Handling needs to be a bit simpler than an  
arbitrary list of possible strings.  In particular, there are three  
primary options of interest:

     1- Stored entity is octet-equivalent to the sent entity.
     2- Stored entity is semantically equivalent to the sent entity.
     3- Stored entity is not the sent entity.

   And that #2 may have some sub-states.  So perhaps values like:

     none
     equivalent
     equivalent:xml
     equivalent:encoding
     equivalent:keyword
     equivalent:encoding,keyword
     modified

   I'm not sure what the use cases are for the sub-states, though,  
but this allows a client to treat all of the equivalence cases in the  
same manner, which I think is a likely case, and is suitable for  
caching.

   Also, I think we might want to note that there may be server  
implementations where both state IDs are in lock-step with each  
other.  For example, if property storage tied to the entity storage  
(eg. my DAV server uses file metadata for property storage), then an  
update to one looks like an update to the other (they share a time  
stamp).  This is potentially less efficient, but should still work.

   Are we sure that Resource-State can't be folded into ETag and  
needs to be it's own header?

   It may be useful for the server to be able to specify that a state  
ID/ETag is temporary and expires in some number of seconds.  This may  
be a good solution to the Apache weird ETag problem.  Rather than  
issuing a weak ETag, Apache would ideally issue a temporary ETag.   
For example, "T:1/computed-etag-here" would indicate that the ETag is  
temporary and expires in 1 second.  A client could then wait one  
second and GET the latest version of the resource with a permanent ETag.

	-wsv
Received on Friday, 3 March 2006 20:29:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:49:42 GMT