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

Roy T. Fielding wrote:
> 
> On Aug 6, 2007, at 2:32 PM, Henrik Nordstrom wrote:
>> 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.
> 
> Yes, it should be sufficient, which is what Mark was saying
> in the first place.  But it was (intentionally) defined that way
> over 10 years ago and nobody uses it, even though there are plenty
> of use cases for which it applies. Maybe just adding a lot more
> text to how Content-Location should be interpreted for all methods,
> and how Cache-control/Expires/ETag apply along with it, will be
> enough to make people use it as specified.  *shrug*

 From the discussions over on the Atom mailing list, few people realize 
that Content-Location can be used that way by just looking at the spec.

Let's clarify it.

 > ...
>> 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.
> 
> I don't see why this keeps coming up.  PUT does not vary.  If you PUT
> to a negotiated resource, the resource must do one of:
> 
>    1) change the state of all the variants in accordance with that
>       PUT (which may involve quite a bit of background magic,
>       depending on how those other variants are defined/generated
>       from a common resource model);
> 
>    2) redirect the PUT to a non-negotiated URI; or,
> 
>    3) return 405 (method not allowed) or some other error code.
> 
> In particular, HTTP does not allow the fourth option of
> 
>    4) change only the variant that shares the same Content-Type or
>       Content-Language, or which might be indirectly identified by
>       looking at the Accept* headers.

Again, I agree, but that's another aspect of HTTP people get confused 
about, and in this case, I'll blame the spec, not the people trying to 
decipher it.

> ...

Best regards, Julian

Received on Tuesday, 7 August 2007 12:30:25 UTC