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

Mark Nottingham wrote:
> 
> 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.

That would be correct, but "ETag" isn't an entity-header 
(<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.7.1>) but a 
Response Header 
(<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.6.2>).

Which of course leads to the question: what's the difference??? Looking 
at 6.2...:

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

...seems to be relevant here as it really seems to support the 
"the-etag-is-for-the-entity-you'd-get-on-a-subsequent-GET" world view.

So unless I misread that part, RFC2616 indeed seems to say what ETags in 
PUT responses mean. Which is good. Because we then just need to clarify; 
and can also think about extensions such as in 
<http://greenbytes.de/tech/webdav/draft-whitehead-http-etag-00.html#rfc.section.5>.

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

Agreed (including the very last part :-).

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

I'm with you that there seems to be a problem. Do you have a suggestion 
how to fix it?

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

Best regards, Julian

Received on Tuesday, 4 April 2006 18:49:18 UTC