RE: i107

Yves Lafon wrote:
> 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.
...
> 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

Received on Friday, 1 August 2008 16:15:36 UTC