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

From: Julian Reschke <[email-masked]>
Date: Wed, 01 Aug 2007 02:07:56 +0200

Henrik Nordstrom wrote:
> On tis, 2007-07-31 at 22:37 +0200, Julian Reschke wrote:
> 
>> I think that's one of those unresolved issues, remember that other draft?
>>
>> RFC2616 states:
>>
>> "The ETag response-header field provides the current value of the entity 
>> tag for the requested variant."
>>
>> So what would returning ETag on an empty PUT response mean in this case?
> 
> You mean in a 204? It's quite well defined imho.

What if it's a 200 and the entity said "PUT request succeeded"?

> And in this case it's even more well defined. The 207 response IS the
> requested variant, and is the same as the 200 response to the other
> location.

Last time we discussed this at length (something like 18 months ago), 
the consensus was that "the request variant" is what you would get if 
you would send a GET request with the same set of headers.

PROPFIND, after all, does *not* return a representation of the resource 
at the Request-URI.

Maybe we should focus on 
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i69>, then?

> ...
>> Well, but the resource you send PROPFIND to is a *different* resource 
>> from the one you get an URI for in GET-Location. Otherwise, you could 
>> have used GET to retrieve the properties in the first place, right?
> 
> Well, when you have learnt the URI then you can. As demonstrated by your
> second If-None-Match example in A.1.

Yes.

> Content-Location is a property about the response entity, not the
> resource processing the request.

Yes, indeed. Looking at what I actually wrote about this in 
<http://greenbytes.de/tech/webdav/draft-reschke-http-get-location-latest.html#rfc.section.B.2>:

----
Section 14.14 of [RFC2616] states:

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

However, the purpose of "GET-Location" is to enable the server to 
provide a permanent replacement URI.
----

> ...

Best regards, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Wed, 01 Aug 2007 03:19:28 +0200

> What if it's a 200 and the entity said "PUT request succeeded"?

Better to use 201 then if you want to return the ETag of the object
created.. I don't think you can return any meta about the created object
in a 200 response to PUT, unless you want to return the object itself..

Personally I consider it a specification fault that 201 should not be
used when a PUT request replaces or modifies an existing resource.
Especially so on a versioned server where the PUT actually creates new
resources besides the modified one..

> PROPFIND, after all, does *not* return a representation of the resource 

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

> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i69>, then?

Or alternatively on the faults of WebDAV and how it does not fit the
HTTP cache model very well? Also applies to CalDAV, or any other
extension adding new "GET-like" methods to be used on the same
Request-URI.

For what is in RFC2616 the "requested entity" based on GET is quite
sane. It's not a 100% match, but close. The main exceptions is OPTIONS
and TRACE, sharing the same problems as PROPFIND. The "solution" in
RFC2616 is "Responses to this method are not cacheable.", which is what
we are trying to get away from in this discussion.

On a related note it's worth remembering that PROPFIND (or any "unknown
method") automatically invalidates any cached objects (all variants) at
the request-URI in caches just following RFC2616. (last paragraph of
13.10).

> provide a permanent replacement URI.

Content-Location is as permanent in the this context I'd say.

Content-Location indicates the actual/original location of the entity
contained in the message, to be used when different from the
Request-URI, and can be used in a GET to retreive just that entity.

Note: Resources indicated by Content-Location should not be subject to
content negotiation. This isn't spelled out in clear text in the RFC,
but defined indirectly by the cache model which only allow one current
entity per Content-Location per Request-URI (13.6, last paragraph), and
also the fact that Content-Location is supposed to refer to the original
location of where this entity can be accessed individually.

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Wed, 01 Aug 2007 10:20:56 +0200

> results which is different from the request-URI resource..

My understanding was that the requested variant is independent of the 
request method.

We really need to clarify this.

> the request-URI in caches just following RFC2616. (last paragraph of

Good point. So RCF4918bis (and other specs) should state when this is 
not the case, such as for PROPFIND / REPORT / SEARCH.

> Request-URI, and can be used in a GET to retreive just that entity.

It seems to me that this will only work under your definition of 
"requested variant". So we really need to work on that issue.

> location of where this entity can be accessed individually.

Do you think this requires a clarification in the spec?

Best regards, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Mon, 06 Aug 2007 18:25:49 +0200

> My understanding was that the requested variant is independent of the 

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

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.

I dislike trying to add new "URI" header formats with their own parsing
requirements, which is my main objection to your new proposed header.

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 Aug 2007 19:49:02 +0200

> Doesn't make much sense in PROPFIND, but then a whole lot doesn't..

Right.

> of the PROPFIND entity. I'd propose Content-ETag for this purpose.

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

> requirements, which is my main objection to your new proposed header.

Understood. Note that the header format is borrowed from the "Link" 
header, though.

Best regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 6 Aug 2007 13:34:04 -0700

On Aug 6, 2007, at 10:49 AM, Julian Reschke wrote:
>>> My understanding was that the requested variant is independent of  
>>> the request method.

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

---

From: Julian Reschke <[email-masked]>
Date: Tue, 07 Aug 2007 00:01:06 +0200

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

> what a cache can do with the provided content according to those

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

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 6 Aug 2007 16:00:46 -0700

On Aug 6, 2007, at 3:01 PM, Julian Reschke wrote:
> Everything in the protocol as defined by RFC2616 still means the  
> same thing in my proposal. It's just *extending* it.

RFC 2616 is a specification of the protocol.  The actual protocol is
how HTTP is ideally implemented in the real world (i.e., something
which, once implemented, we would say is free of communication bugs).
If RFC 2616 is the protocol, then the protocol cannot be revised.

What you are calling GET-Location is Content-Location.  I don't care
what you have to change in RFC 2616 in order to make that understood
by others -- changing the specification is irrelevant compared to
adding yet another redundant feature to an already bloated protocol.

....Roy