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

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*

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

That's because they should have been forbidden.  The entire point of
the Web is to increase the number of identifiable resources (hence,
linkable information).

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

No.  The variant is not an entity.  Think of variant as the target
of a request once URI+Vary-fields is taken into account.  It is the
resource-as-subdivided-by-negotiation, which was the original definition
before it got mixed up in committee.  Now, if we add the notion of
a method that acts by indirection (PROPFIND), then we merely add
that notion to the definition in general.

    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.

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

HTTP requires that PUT only be used to directly modify a resource,
since any other interpretation would not allow for option (1) and
thus would not match the method semantics.

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.

That is why most negotiated URIs should respond to state-changing
operations with a redirect to the specific authorable resource(s)
of which the negotiable resource is composed.  Negotiable URIs
are just another form of dynamic content generation, and should
be handled in the same manner unless that generation is very
simple, such as a resource that negotiates deflate content encoding
in which the result of authoring one (un)compressed variant is
easily applied to the other (un)compressed variant.

....Roy

Received on Monday, 6 August 2007 22:52:38 UTC