draft-whitehead-http-etag, Content-Location and 200 OK

draft-whitehead-http-etag-00 section 4.1 points out problems with the  
semantics of ETags in responses; specifically, saying that while  
their semantics is covered in 201 responses (depending on how you  
interpret "requested variant"), the specifications of 200 and 204 are  
silent about this.

I don't think that's quite the case for 204, which says;
> The server has fulfilled the request but does not need to return an  
> entity-body, and might want to return updated metainformation. The  
> response MAY include new or updated metainformation in the form of  
> entity-headers, which if present SHOULD be associated with the  
> requested variant.
Although it's a SHOULD-level requirement, arguably this is enough.

I think the real problem is that 200 is under-specified (or over- 
loaded); while it works well with GET responses, several methods  
(POST, PUT, DELETE) use 200 responses to transfer a successful status  
entity, separate from the entity that would have been returned upon a  
successful GET (what some might call an "instance" or  
"representation; *ducks*).

Because of this, there's a potential conflict between the entity  
headers for the actual response message, vs. those that would be  
returned upon a GET. This isn't the case with 201 and 204, which can  
only convey a status message or nothing, respectively.

I don't think this problem is limited to ETags; e.g., I have users  
who want to return a Content-Location on the response to a PUT,  
because the GET would return a C-L, but they can't because of this.

In a strict reading, C-L applies to the entity it appears within,  
although there are inconsistencies; e.g., in 14.14,
> The Content-Location entity-header field MAY be used to supply the  
> resource location for the entity enclosed in the message when that  
> entity is accessible from a location separate from the requested  
> resource's URI.
vs. 14.30,

> Note: The Content-Location header field (section 14.14) differ from  
> Location in that the Content-Location identifies the original  
> location of the entity enclosed in the request. It is therefore  
> possible for a response to contain header fields for both Location  
> and Content-Location. Also see section 13.10 for cache requirements  
> of some methods.

Am I making sense?

Until this is cleared up, I think I'm going to tell people to use 204  
No Content when they want to update a resource's metadata on a PUT  
response.

--
Mark Nottingham
mnot@yahoo-inc.com

Received on Monday, 3 April 2006 22:12:58 UTC