Re: I-D ACTION:draft-reschke-http-get-location-00.txt

On Aug 6, 2007, at 10:49 AM, Julian Reschke wrote:
> Henrik Nordstrom wrote:
>> On ons, 2007-08-01 at 10:20 +0200, Julian Reschke wrote:
>>> Henrik Nordstrom wrote:
>>>> ...
>>>> It's a bit special indeed as it doesn't act on the requested  
>>>> resource
>>>> itself.. For PROPFIND the requested variant is clearly the PROPFIND
>>>> results which is different from the request-URI resource..
>>>> ...
>>> My understanding was that the requested variant is independent of  
>>> the request method.
>> Right.. it is. Or at least thats the most intelligble definition  
>> of it.
>> Doesn't make much sense in PROPFIND, but then a whole lot doesn't..
>
> Right.
>
>> So a new header is required for PROPFIND to be able to return the  
>> ETag
>> of the PROPFIND entity. I'd propose Content-ETag for this purpose.

No, just use ETag and define it to make sense.

> If we could use Content-Location for the location (which I don't  
> think), I'd be +1 on that.

You can use Content-Location.  Julian, the argument for the
GET-location field is simply wrong.  Section B.1 tells us we should
redefine the protocol to support incompetent implementations that
are required by HTTP to support 303 redirections already. Section B.2,
about Content-Location, takes the description of linking out of context.
In both cases, the spec is talking about replacement URIs for the sake
of link editing the original reference, not about how one might reuse
the new URI as a reference to the content or redirected resource.

The max-age functionality is incompletely redundant to what
can be provided in cache-control.  Yes, cache-control can specify
the cache behavior for *both* the non-GET response and the provided
just-like-GET response, since they both have the exact same cache
characteristics for the content.  All you have to do is define
what a cache can do with the provided content according to those
fields already defined.

Note, however, that you must define some limitations to this type
of indirect reuse in order to prevent cache poisoning.  For example,
the Request-URI and Content-Location should share the same base URL
prefix (up to the last slash character) in order to prevent a
response in some other namespace from poisoning the cache of some
unrelated resource simply by claiming the content-location.

....Roy

Received on Monday, 6 August 2007 20:34:14 UTC