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

On 2006/04/04, at 12:25 PM, Julian Reschke wrote:

> Mark Nottingham wrote:
>> ...
>> 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."
>
> The problem is that the group of people interested in this topic (=  
> the readers of this mailing list) do not seem to agree upon whether  
> the spec needs to be clarified, and if it needs to, how to proceed.  
> Every few months we're exchanging a few mails about this topic, but  
> in the end the discussion dies away.

I've heard of this problem before. It's a pity, because the  
classifications in the spec aren't helpful, and occasionally  
misleading. *sigh*

>>> 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?
>
> That's correct, meaning the restriction just to return those  
> headers classified as "Entity Headers" in RFC2616 would need to be  
> relaxed. That shouldn't break anything.

Works for me.

--
Mark Nottingham
mnot@yahoo-inc.com

Received on Tuesday, 4 April 2006 19:35:30 UTC