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

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

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

It's probably at least as effective as adding a new status code, and
with the positive sideeffect that implemented actually finally
understand Content-Location.

Yes, there is lots of broken intermediaries returning broken
Content-Location headers, but I do not consider that a problem for
making good use of the header. Most of those same intermediaries would
have just as big problems with any extension added.

>     variant
>        The ultimate target resource of a request after indirections
>        caused by content negotiation (varying by request fields) and
>        method association (e.g., PROPFIND) have been taken into account.
>        Some variant resources may also be identified directly by their
>        own URI, which may be indicated by a Content-Location in the
>        response.

Works for me I think..

> I don't see why this keeps coming up.  PUT does not vary.

Probably because Content-Location hasn't been well established so we
keep forgetting about it..

> 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);

Or 1b) Change the URI into a non-negotiated resource which is what I
suppose will happen on most servers..

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

Ok. Good to have that cleared out.

> The same should apply to PATCH.  The Accept headers define what is
> acceptable in the response entity, which is not recommended for a
> state-changing operation.  The Content-* headers define the entity
> that is included in the request payload (the patch data).  Even
> when the patch data contains metadata that indicates which variant
> is being patched, the result of the state change must be reflected
> in all variants.  Otherwise, PATCH does not have uniform semantics.

Makes perfect sense.

Regards
Henrik