i22: ETags on PUT responses

<http://tools.ietf.org/wg/httpbis/trac/ticket/22>

In Vancouver, discussion focused on the definition of ETag as a  
response header, rather than an entity header; 2616 says:

> The ETag response-header field provides the current value of the  
> entity tag for the requested variant.

and:
> The response-header fields allow the server to pass additional  
> information about the response which cannot be placed in the Status-  
> Line. These header fields give information about the server and  
> about further access to the resource identified by the Request-URI.
>

Below, I'll try to summarise my understanding of where we now sit;  
please correct me if I haven't got it right.

A client sends a PUT request Rq to resource A, returning ETag E in  
response Rs.

E applies not to Rs, nor Rq, but to the response that would be  
generated if a GET request to A were made immediately after the PUT,  
with any selecting headers applied.


Likewise, a client sends a POST request Rq' to resource A, returning  
ETag E' in response Rs', which also contains a Content-Location header  
pointing to A'.

E' applies not to Rs' or to Rq', nor to A', but again to the response  
that would be generated if a GET request to A were made immediately  
after the POST, with any selecting headers applied.


The same not only applies to ETag, but also appears to apply to Vary  
(being a response header, and also being necessary to indicate which  
headers would be used to select the variant).


If this is the case, it seems like the resolution to i22 is to;

1) clarify the nature of ETag as a response header (e.g., giving  
examples, rewording text)
2) note that some implementations may behave differently, based upon  
prior agreement with clients.

#1 is probably going to involve the resolution of i69 to some degree.

Make sense?


--
Mark Nottingham     http://www.mnot.net/

Received on Friday, 4 January 2008 05:19:57 UTC