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

On 2006/04/04, at 11:47 AM, Julian Reschke wrote:
>
> 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>).

Ah, my bad. Thought I'd checked that.

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

OK. If we were *really* picking apart 2616, I'd think a re-org of the  
header classifications would be in order; Jeff M took a stab at this  
in "Clarifications of the Fundamentals of HTTP."

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

Not sure yet, but I was thinking about a new 2xx status code to be  
explicitly used as a successful non-GET/POST response (both GET and  
POST responses can be cacheable). Problem is, 200 is hard-wired as  
the code to use in a number of places (e.g., the definition of PUT).

OTOH, 204 may be good enough for most cases; is it that often that  
it's necessary to return an entity body with the PUT response? If the  
scope of metainformation updates in the definition of 204, or the  
definition of entity-headers, can be adjusted just a bit, it should  
be adequate, I think. After all, what other possible meaning could an  
ETag have in a 204 response?

--
Mark Nottingham
mnot@yahoo-inc.com