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

From: Julian Reschke <[email-masked]>
Date: Mon, 30 Jul 2007 20:19:58 +0200

Hi,

this is a proposal that may build a bridge between the "hidden" Web 
(PROPFIND/REPORT/SEARCH and similar methods), and the pure Web (GET, 
cache validators).

HTML and XML versions at 
<http://greenbytes.de/tech/webdav/#draft-reschke-http-get-location>.

Feedback appreciated,

Julian

[email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
> 	Title		: The Hypertext Transfer Protocol (HTTP) GET-Location header
> 	Author(s)	: J. Reschke
> 	Filename	: draft-reschke-http-get-location-00.txt
> 	Pages		: 15
> 	Date		: 2007-7-30
> 	
>    Several hypertext transfer protocol (HTTP) extensions use methods
>    other than GET to expose information.  This has the drawback that
>    this kind of information is harder to identify (missing a URL to
>    which a GET request could be applied) and to cache.
> 
>    This document specifies a simple extension header through which a
>    server can advertise a substitute URL that an HTTP client
>    subsequently can use with the GET method.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-reschke-http-get-location-00.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [email-masked] with the word unsubscribe in the body of 
> the message. 
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username "anonymous" and a password of your e-mail address. After 
> logging in, type "cd internet-drafts" and then 
> "get draft-reschke-http-get-location-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-reschke-http-get-location-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 31 Jul 2007 20:30:41 +0200

> <http://greenbytes.de/tech/webdav/#draft-reschke-http-get-location>.

For me it would make more sense if ETag/Last-Modified was returned in
the response, and the GET location of the same response resouce was
indicated using Content-Location.

The use of Content-Location is also needed to make use of the cache
invalidation rules, allowing automatic invalidation of cached results on
modifications.

PROPFIND /collection/ HTTP/1.1 
Host: example.com
Depth: 1
Content-Type: application/xml

<propfind xmlns="DAV:">
  <prop>
    <resourcetype/>
  </prop>
</propfind>

HTTP/1.1 207 Multi-Status
Content-Type: application/xml
Content-Location: /collection/;members
ETag: "123"
Cache-Control: max-age=3600

<multistatus xmlns="DAV":>
  <response>
[...]

GET /collection/;members HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Content-Type: application/xml
ETag: "123"
Cache-Control: max-age=3600

<multistatus xmlns="DAV":>
  <response>
[...]

Content-Location MAY also be included to keep the two responses completely equal apart from the status code, but is redundant.

Also note that weak etags is sufficient for caching of results (end of A.1).

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Tue, 31 Jul 2007 20:46:30 +0200

> indicated using Content-Location.

The problem with returning the ETag is that ETag is defined to apply to 
the resource at the Request-URI, which, in this case, is incorrect, right?

WRT to Content-Location: RFC2616 says in 
<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.14>:

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

I don't think this is the case here...

> invalidation rules, allowing automatic invalidation of cached results on

I'm not sure I understand. Could you provide an example?

> ...
> ...

Thanks for mentioning status codes, I guess we need to say something 
about it.

> Also note that weak etags is sufficient for caching of results (end of A.1).

Understood. I didn't want to mention them over here for obvious reasons :-)

So, if we can fit this functionality into existing servers, that would 
be great. Before coming up with this particular proposal, I tried that 
and came to the conclusion that it didn't work well with how 
Content-Location is currently defined...

Best regards, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 31 Jul 2007 21:54:56 +0200

> the resource at the Request-URI, which, in this case, is incorrect, right?

No. It's a cache validator for the response entity.

In case of WebDAV I would in general recommend the use of the same ETag
on the resource and it's related properties etc..

> I don't think this is the case here...

Isn't it? To me it sounds like a 100% match.. The location of the
resource corresponding to this particular response entity at the time of
the request.

See also the next sentence in the same paragraph:

"Future requests MAY specify the Content-Location URI as the request-
URI if the desire is to identify the source of that particular
entity."

Again, entity in this context is the message entity, not the server
resource.

> I'm not sure I understand. Could you provide an example?

Hmm.. reading the RFC again.. no the invalidation doesn't work out
properly without further additions to the invalidation model. It doesn't
apply fully in this case, at least not how it's written.

Would make sense if invalidations based on Content-Location were
generalized to in invalidate the Content-Location URI if the entity seem
to differ. Apart from making a lot of sense in the discussed case it
also makes caching and invalidation of negotiated entities more robust
where otherwise the cached negotiated entity Content-Location entity
could easily get out of sync.

I.e. having something like the following in 13.10 after the list of
methods would make great sense I think:

"Or if the response to any other method has a Content-Location header
and the cached entity at that URI differs from the current entity at
that URI (as would be indicated by a change in Content-Length,
Content-MD5, ETag or Last-Modified), then the cache SHOULD treat the
cache entry as stale."

Most of the text is copy-pasted from HEAD, where the similar action on
the request-URI entity is a MUST.

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Tue, 31 Jul 2007 22:37:11 +0200

> No. It's a cache validator for the response entity.

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?

> on the resource and it's related properties etc..

As properties and "content" can be manipulated independently, that would 
be not optimal. In particular there are live properties who change 
values without any write access, unfortunately (DAV:lockdiscovery).

> resource corresponding to this particular response entity at the time of

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?

> the request-URI entity is a MUST.

That may be a good idea; we probably should make that a separate 
RFC2616bis issue...

Best regards, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Wed, 01 Aug 2007 00:37:17 +0200

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

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.

> values without any write access, unfortunately (DAV:lockdiscovery).

Felt optimal when I wrote it but you are right. They live their own
lifes.

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

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

> That may be a good idea; we probably should make that a separate 

Yes.

Regards
Henrik