Subject: RE: i107

From: Yves Lafon <[email-masked]>
Date: Fri, 1 Aug 2008 08:26:41 -0400 (EDT)

On Thu, 31 Jul 2008, Brian Smith wrote:

>
> Henrik Nordstrom wrote:
>> On tor, 2008-07-31 at 12:14 -0500, Brian Smith wrote:
>>> I assume by "the resource" you mean the resource at the original
>>> request URI, not the resource at the Content-Location URI.
>>
>> Content-Location IS the specific URI to this resource. Or if
>> you like the non-negotiated direct access URI to a specific
>> variant of a resource.

+1 (and btw, editing http://www.example.com/bar/ is quite painful as most 
servers won't give a CL with the "non-negotiated" URI (in this case it 
not really conneg)).

>>> RFC 2616 doesn't say that the client may delete any of the
>> variants of
>>> http://example.org/foo.html by sending a DELETE request to
>>> http://example.com/foo.html.
>>
>> To me it's exacly what it says. Quote from p3 6.7 Content-Location:
>>
>>    The Content-Location value is not a replacement for the original
>>    requested URI; it is only a statement of the location of
>>    the resource corresponding to this particular entity at the
>>    time of the request.
>
> example.org says that the entity that it is returning in the response is
> available at the time of the request at http://example.com/foo.html, which
> is not even the same domain. RFC 2616 doesn't say that must be a true
> statement; in fact, in another part the specification makes it quite clear
> that we shouldn't make any such assumptions.

Not the same domain... Is that very different if the URI in CL was 
http://example.com/bar/foo.hml ? Are you sure that if the URI are in the 
same domain, the URI is controlled by the same group of people? The same 
domain assumption works somehow in practise, but is in theory plain wrong.

>
>>    Future requests MAY specify the Content-Location URI as
>>    the request-URI if the desire is to identify the source
>>    of that particular entity.
>
> That *doesn't* say that editing the resource at the Content-Location URI
> will have any effect on any variant of the resource identified by the
> original request URI.

Nothing is said about _editing_ the resource, note that there is an issue 
as well with validators (ETag being a response header and not an entity 
one, see attempts with structured ETags [RFC 2295] etc...)

>>> an extension to HTTP. In any case, there may be more than
>>> one variant of the resource at the Content-Location URI,
>>> so Content-Location doesn't even address a specific
>>> variant of *any* resource.
>>
>> No. The Content-Location URI is not supposed to be a
>> negotiated resource. If it is then the server implementation is wrong.
>
> The specification doesn't say that anywhere, although I agree that some of
> the wording kind of hints to it. In practice protocols like AtomPub that
> place extra meaning when Location=Content-Location mean that
> Content-Location will often reference a content-negotiated resource (again,
> because of Vary: Accept-Encoding) which is beyond the application's control
> (again, because of things like encoding proxies or mod_deflate).

(let's digress on the use of Accept-Encoding/Content-Encoding when 
TE/Transfer-Encoding is better suited)

Suppose you want to edit http://exampe.com/bar/foo.html it is served using 
mod_deflate, so an ETag of "aofidrjfoer"-gzip is added (yuck, but at least 
it's different than the non-compressed version, even if this is not valid)
And you have a nice Content-Encoding: gzip.
Now edit, (wash, rince,) save... Without a real CL, you will save a 
compressed version to an originally  non compressed resource. Not a big 
deal, as the server should DTRT, store the compressed content and adjust 
its metadata. But some other people, editing directly on the file system 
will find it surprising to edit binary data instead of HTML.

Ok, so add a CL in this case ? Ok, PUT will be done on 
http://example.com/bar/foo.html.gz, then you didn't change the original 
one and have two different document (with different content) served using 
conneg on Accept-Encoding.

I am still wondering why support for TE/Transfer-Encoding is so weak...
(end of digression ;) )

>> If the server can not provide unique URIs to each variant
>> then no Content-Location should be returned.
>
> The specification says only the converse of that:
>
>   A server SHOULD provide a Content-Location for the
>   variant corresponding to the response entity; especially in
>   the case where a resource has multiple entities associated
>   with it, and those entities actually have separate locations
>   by which they might be individually accessed, the server
>   SHOULD provide a Content-Location for the particular
>   variant which is returned.
>
> 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.
>
>>> It is unrealistic to assume that we never PUT to negotiated
>>> resources because many (on some servers, all) resources are
>>> negotiated as  "Vary: Accept-Encoding" at least.
>>
>> Indeed. The catch is that implementations of dynamic
>> content-encoding hasn't really followed the entity variant
>> model of HTTP that well.. so the Content-Location model fails
>> for such setups. And clients have to work around it by not
>> using Accept-Encoding if they want to be able to update the
>> resource.
>
> The Content-Location model fails because it requires a trust model that HTTP
> leaves undefined.

Well, what kind of trust model would work? Are you trusting the header and 
content you receive from an origin server, if not sent using HTTPS?

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

As I said above the main issue is that CE is used when TE is really meant.

> But, it is easy to show that the same holds for Content-Type too. Let's say
> I have a resource http://example.org/my-girlfriend with image/png and
> image/jpeg variants, and I issue this request:
>
> PUT /my-girlfriend HTTP/1.1
> Content-Type: image/jpeg
> Accept: image/jpeg
> ...
>
> It would be very surprising for the server to return a picture of my old
> girlfriend for this request:
>
>   GET /my-girlfriend HTTP/1.1
>
> while simultaneously returning a picture of my new girlfriend for this
> request:
>
>   GET /my-girlfriend HTTP/1.1
>   Accept: image/jpeg
>
> 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.

The existence of variants are orthogonal to the fact that server have 
content negociated resource.

If you have /my-gf.png and /my-gf.jpeg, your intent is probably to do 
fancy transcoding to update one when the other is edited, because you 
know that there is a semantic link between the two URIs, and the link is 
not the fact that /my-gf is a conneg resource. In your example, doing a 
PUT on /my-gf /my-gf.png or /my-gf.jpeg should in theory lead to the same 
thing, update all versions, but it is way beyond what HTTP gives you, it's 
server side logic for this particular set of resources.
Cheers,

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

---

From: Henrik Nordstrom <[email-masked]>
Date: Fri, 01 Aug 2008 14:49:54 +0200

> 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

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

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

> very least, servers must be *allowed* to operate that way, if they are not

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

---

From: "Brian Smith" <[email-masked]>
Date: Fri, 1 Aug 2008 11:14:53 -0500

Yves Lafon wrote:
> http://example.com/bar/foo.html.gz, then you didn't change 
> the original one and have two different document (with 
> different content) served using conneg on Accept-Encoding.
...
> Well, what kind of trust model would work? Are you trusting 
> the header and content you receive from an origin server, if 
> not sent using HTTPS?

Again, using Content-Location as a substitute URI for editing is going
beyond what RFC 2616 specifies. Whatever extension to HTTP that defines such
a scheme can define how everything works together.

> The existence of variants are orthogonal to the fact that 
> server have content negociated resource.
> 
> If you have /my-gf.png and /my-gf.jpeg, your intent is 
> probably to do fancy transcoding to update one when the other 
> is edited, because you know that there is a semantic link 
> between the two URIs, and the link is not the fact that 
> /my-gf is a conneg resource. In your example, doing a PUT on 
> /my-gf /my-gf.png or /my-gf.jpeg should in theory lead to the 
> same thing, update all versions, but it is way beyond what 
> HTTP gives you, it's server side logic for this particular 
> set of resources.

I agree, if I expose all three of those resources. But, in the example, only
one resource (with two variants) was exposed, not three separate resources.
My point is that in such a situation, you cannot address any of the
individual variants with a PUT request, so it is only sensible to replace
all the variants if any of them are replaced, unless there is something in
the client request that suggests otherwise. In particular, the Accept-* and
Content-* do not make any such suggestion, but WebDAV's Label header does.

>From there, I further argue that since the server is going to be editing all
the variants at once, it should also match the validators against the
request with the validators of all the variants (which is what i107 is
actually about). At the very least, servers must be allowed to work that
way. I do agree with Mark when he said that it is confusing for a "304 Not
Modified" response to return an ETag that isn't even listed in the
If-None-Match header. I think maybe it *does* make sense to say that
conditional GET/HEAD requests should only return 304 if the validators match
for the selected variant. It is for the other kinds of requests (ones like
PUT/DELETE that would return 412 instead), where the wording about a
"similar GET request" doesn't make sense.

Cheers,
Brian