RE: i107

tor 2008-07-31 klockan 08:24 -0500 skrev Brian Smith:

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

I disagree.

You can't cache content across Request-URI and Content-Location as being
authorative for the Content-Location URI, but it's fine to use the
Content-Location URI for updates and other modifications to the
resource.

The specs is imho quite fine on when Content-Location can or should be
used. Possibly with the exception for defining the base URI, which is
fine in theory but not implemented by anyone.

> > 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 carries entity headers. Content-* headers is valid request headers
in a PUT request, and describes the properties of the entity carried
within the request.

> 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

Yes, ofcourse. Sorry for not making that clear, thought it was obvious..

> However, the evaluation of the
> conditionals is different than deciding which variants are to be edited. 

Yes, which was my point.

> Where is the meaning of Vary on a PUT response defined? As far as I can tell
> it is meaningless.

Not entirely. The PUT response do carry meta headers for the created
resource. But yes, probably...

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

Indeed. But more importantly I already demonstrated that the selectors
in the PUT request has nothing to do with the created resource..

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

RFC2616 doesn't define how a PUT affects the server state at all. But it
is implicitly assumed you never do PUT to negotiated resources and only
non-negotiated resources and that the request entity is normally stored
as-is. The effects of content negotiation on PUT requests is not
explored at all in the spec, except for Content-Location indicating the
actual resource URI of the created/modified resource.

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

The example I gave earlier where PUT of a swedish variant is dependent
on the validator for the english variant.

Regards
Henrik

Received on Thursday, 31 July 2008 15:22:12 UTC