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

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.

Right now, do we have just have an editorial problem, getting the 
changes that Jim Gettys made in <draft-gettys-http-v11-spec-rev-00> into 
the XML version of RFC2616, thereby getting (hopefully) easy-to-review 
diffs? In that case, I'm volunteering to integrate them.

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

Best regards, Julian

Received on Tuesday, 4 April 2006 19:27:27 UTC