RE: i107

Henrik Nordstrom wrote:
> On mån, 2008-07-28 at 16:56 +0100, Mark Nottingham wrote:
> Remember that HTTP is defined in such way that each resource 
> variant SHOULD (but not MUST) have an unique URL of it's own, 
> as indicated by Content-Location. If you want to DELETE just 
> a specific language then this is the URL you use in DELETE. 

In a thread earlier this year, we basically came to the conclusion that
Content-Location is generally useless for anything except cache invalidation
due to the possibility of spoofing.

> For PUT it's less obvious, as how a PUT updates the server 
> state is implementation defined. But my reading is that for 
> PUT to content-negotiation enabled request-URI then the 
> content headers (Content-*) possibly define the resource
> variant to be stored and negotiated headers (i.e.
> Accept-* as indicated by Vary) the variant to match in
> conditionals used in the PUT request.

Where do you get that? Content-* describe the request entity, Accept-*
describe the preferred form of the response entity. Any use of those fields
for other purposes--especially addressing individual variants--is giving
these fields a meaning they are not defined to have.

PUT is defined in terms of editing resources, not editing variants of
resources. Unless my request has a header that indicates some extension to
HTTP is wanted, I expect any PUT to a resource URI to replace all the
variants for that resource. I don't see how any other reading of the
definition of PUT makes sense. Similarly, DELETE is defined as a request to
"delete the resource identified by the Request-URI," not to delete some
subset of its variants.

Further, PUT and DELETE invalidate all cached entities for the Request-URI,
regardless of any other header field value. It wouldn't make sense to
require that unless the server is allowed to modify any or all variants of a
resource based solely on the Request-URI.

> PUT /resource HTTP/1.0
> If-Match: "a"
> Accept-Language: en
> Content-Language: sv
> 
> MAY stores the Swedish variant of the resource IF
> 
> * the english variant exists and has etag "a"
> * content-negotiation is enabled on the resource

Yes, but not "if and only if." I think it makes sense to say that clients
should send the same request headers (as much as possible) in a conditional
POST/PUT/DELETE request that they sent in the GET request that retrieved the
validators, in order to avoid 412 responses from servers that do selection
before they evaluate conditionals. However, the evaluation of the
conditionals is different than deciding which variants are to be edited. 

> The response to the PUT request then carries a ETag for the 
> created variant, and unique Content-Location, and Vary 
> indicating the axis of variance on the resource.

Where is the meaning of Vary on a PUT response defined? As far as I can tell
it is meaningless. Plus, a resource can have more than one applicable "axis
of variance" as (Resource-URI -> Vary) is not a function, as you said in the
other thread.

> If content negotiation is not enabled for the request-URI 
> then the PUT simply replaces any existing resource (and all 
> variants) at the request URI.

There is no need to qualify it with "If content negotiation is not enabled."
The server should replace and/or regenerate all the variants at the request
URI unless the request indicates otherwise. RFC 2616 doesn't define any
mechanism for the client to indicate that only a particular variant should
be edited. RFC 3253 does have the "Label" request header field to address a
particular variant. 

> Many servers may well have this 
> as the only implementation requiring PUT on specific variant 
> unique URLs to create or update negotiated resources, and the 
> structure of those is implementation dependent and not 
> specified in HTTP/1.1. 

That part I agree on. More generally, HTTP/1.1 doesn't provide any mechanism
for editing a specific variant of a resource; it only provides mechanisms
for editing resources in their entirety.

> Servers MAY also use 307 to the to be created variants unique 
> URL if seeing a PUT to a negotiated URL. But it's then not 
> possible to build conditions across variants as above. For 
> many implementations this is perhaps the cleaner approach.

I don't know what you mean by "it's then not possible to build conditions
across variants."

Regards,
Brian

Received on Thursday, 31 July 2008 13:25:14 UTC