Re: New "200 OK" status codes, PATCH & PROPFIND

On mån, 2007-08-06 at 13:11 -0700, Roy T. Fielding wrote:

> > 209 Content Retuned
> 
> okay, but only if it is forbidden as a response to GET.

Agreed. It's only a patch to work around the earlier specification
mistakes allowing 200 OK to be used for "aux information" different from
the requested entity.

But the more I think about this the less convinced I get that a new "200
OK here is your content" status code is needed. Simply providing a
Content-Location or expiry information in the 200 OK should be
sufficient. I.e. a generalisation of the POST rules, adding
Content-Location as an alternative criteria an applying it to any method
unless the method definition says otherwise.

> There is no
> need to make any special reference to Vary or Cache-control -- just
> define all fields to be interpreted as if the request method had been  
> GET.

Fine by me.

> > 210 Information returned
> 
> No way.  That is what Content-Location provides.  We don't need a
> Content-Etag header field -- the Etag response header field would
> always have the same value.

Thats what my gut says as well, but this talk about "requested variant"
got me a bit worried. Currently the concept of "GET like non-GET
methods" fits rather poorly in the cache model of RFC2616.

Well, back on that topic. Here is a definition of "requested variant"
which would work out quite reasonably I think:

requested variant
 the entity returned if the same request had been a GET request
 sent to the Content-Location URI, or Request-URI if no
 Content-Location header is present in the response.

About the only special case where the Request-URI could be used equally
to Content-Location in this is HEAD, but then HEAD is a bit of a special
case in itself..

For many other methods the meaning of Content-Location is very
significant as a simple transition of the request to GET doesn't account
for all the possible variance vectors involved. I.e. a PUT to a Vary:ing
URI might only update one variant of that resource, possibly different
from what the same request as a GET would return. Even more so for
PATCH. And PROPFIND returns information from a different namespace.


Then the cache invalidation rules needs to be refined a bit to avoid
things like PROPFIND flushing all cached variants of the requested URI.
It's not realistic that caches should need to learn every new "GET-like"
method people invent..


Regards
Henrik