RE: i107

On tor, 2008-07-31 at 17:37 -0500, Brian Smith wrote:

> In particular, the specification never says that the server SHOULD NOT or
> MUST NOT provide a Content-Location header when the predicate is false.
> AtomPub and other similar servers will often return a Content-Location
> header that doesn't uniquely identify a variant as I mentioned above.

Then this may need to be clarified.

Content-Location IS a unique object identifier, very similar to ETag,
except that it is not also a validator. There can be no two variants of
the same resource having the same Content-Location.

Content-Location is also supposed to be a unique URI directly addressing
a specific entity (variant) without negotiation. Methods using this URI
should address that specific variant of the resource.

> The Content-Location model fails because it requires a trust model that HTTP
> leaves undefined.

I still disagree on this. The level of trust needed for Content-Location
is not required at the protocol layer imho, and should be assumed by
application.

> I disagree. If the goal is to edit each language variant independently, then
> you need some mechanism to identify the individual variants as separate
> resources. HTTP itself doesn't define any mechanism for doing that; you need
> some extension. That extension might be an extension that simply says
> "Editing the resource at the Content-Location returned for X variant of
> resource Y will update that variant of resource Y" and with a trust model
> added. But, it is not something that exists in HTTP now.

Except for the "trust" you look for it exists very well in HTTP, and I
maintain that this level of "trust" is there.

Yes, a "broken" server will send out invalid Content-Location URIs,
confusing the client to perform updates of another object than expected
or giving out direct references to another object than expected. But
it's not a security issue affecting the URI at the Content-Location
unless the person is also a trusted editor of that URI.

Common sense (and specs) hints that applications should not blindly
trust Content-Location without verification that it makes reasonable
sense, mainly that the host component is identical to that of
Request-URI.

> Again, I disagree. The specification doesn't give any special treatment to
> Content-Encoding.

To that I fully agree, but how it's deployed does give it a quite
special status.. but fortunately the world is slowly aligning with
specifications.

> I understand where you are coming from, but I don't think
> anybody here wants to define a whole set of rules for Content-Encoding
> separate from every other entity header. (Right?)

Rigth. The difference is more at a conceptual level than protocol.

> That is why I use
> Content-Encoding instead of Content-Language in all my examples. It is the
> most common case by far. It is also the one that causes the most problems
> when one tries to define a mechanism for editing individual variants,
> because any mechanism that doesn't allow the server to keep the unencoded
> and encoded variants in sync by default can be shown to be obviously
> defective.

A well behaved nontent-negotiating and transcoding server should update
both if any of them are modified, and is entirely free to do so it it
likes.

And this is where Content-Encoding IS quite different from
Content-Languge.

Content-Type gets somewhere inbetween the two extremes..

> That is why I am so strongly advocating a requirement that PUT and DELETE
> requests on a resource should operate on all variants of the resource by
> default, unless the request somehow explicitly indicates otherwise. At the
> very least, servers must be *allowed* to operate that way, if they are not
> *required* to do so.

Servers are allowed to operate in that way.

Servers are in fact allowed to operate in pretty much any way they like
in these regards as long as it makes sense to their users..

> Also, keep in mind that there is no requirement for the server to return a
> Vary header field on a negotiated response unless the response is cacheable.
> Thus, the client generally has no way of knowing what resources are even
> content-negotiated.

True. But not sure it matters in the context.

Regards
Henrik

Received on Friday, 1 August 2008 12:50:37 UTC