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

Roy T. Fielding wrote:
> On Aug 6, 2007, at 10:49 AM, Julian Reschke wrote:
>> 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.

Roy,

are you really arguing that a client that doesn't grok 303 as defined in 
*RFC2616*, when received upon PROPFIND is "incompetent"? Let's see what 
RCF2616 says:

"The response to the request can be found under a different URI and 
SHOULD be retrieved using a GET method on that resource. This method 
exists primarily to allow the output of a POST-activated script to 
redirect the user agent to a selected resource. The new URI is not a 
substitute reference for the originally requested resource. The 303 
response MUST NOT be cached, but the response to the second (redirected) 
request might be cacheable."

So, as far as I can tell, the only way to use that in PROPFIND would be 
to GET-follow the redirect, and to forget about the alternate URI right 
away. That replaces a single request with two requests, with no apparent 
benefit. Actually, from what RFC2616 says, I would call a client 
re-using the URI returned in "Location" for subsequent requests 
"incompetent".

This is not what the GET-Location proposal is for. It tries to give the 
client a long-lasting substitute URL. 303 does not do that.

I'd also like to point out that I'm not *redefining* the protocol. 
Everything in the protocol as defined by RFC2616 still means the same 
thing in my proposal. It's just *extending* it.

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

I don't think they have the same characteristics. GET-Location allows 
the sever to state:

- here's a PROPFIND reponse you can use for the next 60 seconds, but

- here's a substitute URL you can apply GET to instead for the next 3 
momths.

The point being that once the client has discovered the alternate 
resource, it doesn't need to go through the PROPFIND step anymore for a 
long time.

> ...

Best regards, Julian

Received on Monday, 6 August 2007 22:01:29 UTC