Subject: Re: I-D ACTION:draft-nottingham-http-link-header-01.txt

From: Jamie Lokier <[email-masked]>
Date: Tue, 29 Apr 2008 13:51:08 +0100

Phil Archer wrote:
> I am sympathetic to your proposal for foo-Links - it seems clear and 
> your experiments add weight to it. However, it seems to lose out on 
> flexibility. With Link, anyone can create a new relationship type by 
> providing an absolute URI, it's only relative ones that are tied to the 
> IANA namespace.
> 
> Putting people in a tight corner will lead them to ignore some of the 
> rules and I fear you'll soon see 'links' of the type
> 
> dunno_about_registration-Links:
> 
> so that clashes become rather more likely.

How about:

    Generic-Link: URL=value

Which is required to be written in exactly that form, the URN denotes
the relation type, and the URN is always unquoted, absolute, and in
a canonical form.

It seems to satisfy the same easy parsing and substitution
requirements that motivate foo-Link, while providing the flexibility
of URNs for unregistered relation types.

-- Jamie

---

From: "Brian Smith" <[email-masked]>
Date: Tue, 29 Apr 2008 09:02:25 -0700

Phil Archer wrote:
> I can see that that would work. Would IANA registered links 
> therefore be as simple as:
> 
> stylesheet: /styles.css  ?

It depends on whether there is a need to be able to do thinks like "find and
parse all the links, regardless of the link relation". My suggestion assumed
that was necessary; if so, then the "-Links" suffix (or something like it)
and the uniform syntax would be needed. If "find and parse all the links" is
not an important use case, then no such convention would be needed at all.

> Specifying something with the full IANA namespace would become
> 
> www.iana.org-assignments-link-relations.html-stylesheet: /styles.css

You could do that, but I don't think it is a good idea. I wasn't trying to
suggest a solution for converting IRIs into tokens to be used as header
field names (which would never gain acceptance), nor was I trying to provide
some way of automatically mapping Atom link relations to HTTP header fields
(which isn't a good idea anyway). I was just saying that if somebody wants
to have a "private use" HTTP header field, prefixing the header field name
with their domain name is reasonable way of avoiding collisions.

Regards,
Brian

---

From: "Brian Smith" <[email-masked]>
Date: Tue, 29 Apr 2008 11:44:51 -0700

From: Mark Nottingham [mailto:[email-masked]] 
> On 27/04/2008, at 8:39 PM, Brian Smith wrote:
> > Mark Nottingham wrote:
>
> Are you saying that there are no use cases for a link header 
> in Atom?  
> I find that hard to believe (e.g., link with a relation of 'edit- 
> media' on a media response seems obvious and useful), but if 
> it's so,  
> perhaps the simple answer is to use a separate registry for the  
> header, with the option of registering Atom relations later.

I would like to see an "Edit" header that allows the server to say that
PUT/DELETE requests should be sent to a different request URI. For example,
I want the server to suggest that edit requests for the resource at
http://example.org/foo should be sent to the authenticated URI
https://example.org/foo). However, I want to provide an additional
capability where the user can download a resource at its http:// location,
and then edit it with a conditional (If-Match:) request against its https://
location, without first having to download it from the https:// location. I
think such a mechanism is much more useful than what the simpler Atom "edit"
and "edit-media" mechanism provides.

Similarly, I would like to see something like "alternate". However, I don't
think that every Atom link relation is or will be generally useful outside
of Atom. I already use several link relations that only make sense for Atom
applications. 

> > 1. There is too much flexibility in the syntax of the "rel"  
> > parameter. For
> > example, the following all mean the same thing:
> >      rel=edit
> >      rel="edit"
> >      rel="\e\d\i\t"
> >      rel="http://www.iana.org/assignments/link-relations.html#edit"
> >      ....
> > If you want to be able to catch all variations, then you have to  
> > write a pretty nasty regular expression.
> 
> What leads you to believe that "\d" is the same as "d" in a URI  
> reference?

"\d" and "d" mean the same thing according to the definition of
quoted-string in RFC 2616, AFAICT. We are supposed to unescape
quoted-strings before processing them, right?

> Regardless, regex is often the wrong tool for parsing.

Yes, I agree. That is why I prefer a syntax that doesn't require a parser
that is as powerful or more powerful than regular expressions for common use
cases. 

> > I think the "-Links" header idea allows for uniform syntax 
> > (like the Link header) while still being extremely easy
> > to process.
> 
> This approach didn't work terribly well for entity headers, 

You mean the Content-* ones? I think the problem with that that the HTTP
spec put unreasonable processing requirements on implementations, and the
Content-* prefix didn't provide any useful semantics for implementations
that didn't implement those unreasonable requirements. It may be that the
-Links suffix doesn't provide any useful feature as well--I think "find all
the links, even for link relations I don't know about" is not a useful
feature. But, that is the only one that the Link: header is optimized for. 

> and would further clog up the header registry.

I don't think that this is a problem, as long as they are well-defined and
generally useful across a variety of HTTP applications. The more
well-defined, generally useful, standardized header fields, the better.

> It would also require people to register their links
> in at least two places, and coordinate them over time.

You just suggested a separate registry above to separate Atom-specific and
general-purpose link relations.

> Changing the registration procedures is also not a small 
> thing, since they already have IETF consensus. Similar
> proposals to the ones being put forward
> (e.g., com.foo.link:) have been put forward for media  
> types, and have been shot down quite firmly.

My suggestion for "domain.com-Link" headers was purely for the case where
somebody wanted to use a custom HTTP header privately, without registering
it. And, I'm not married to the "-Links" suffix idea either. (Actually, I
the "-Links" suffix idea doesn't really require any changes to the
registration procedures or any other formal blessing; if you come across a
"-Links" header that you cannot parse as a list of links with parameters,
you would just ignore it, and if you can parse it, then you would just
assume it was a link.)

The point I'm trying to make is that it is easier to process HTTP header
fields when each header field has a single, well-defined purpose, and where
the header field's name indicates its purpose. I think the design of the
Link header goes totally counter to that because it indexes metadata
primarily by its type, and then by its purpose. Imagine if we had
"Integers", "Dates," and "Strings" headers analogous to "Link"; Or, imagine
a "Header" header:

   Header: #(<value>; rel=relationship *(;param=value))

The Link header is just like that except it restricts the value to be a URI
reference. If "Link" is a good idea then "Header" would be even better.

One argument you gave for the Link header was that it was easier to parse
than an Atom document. At first, I agreed, but when I implemented it, I
found it wasn't a significant improvement. I pointed out already that it is
impossible to use mod_headers to process the Link header effectively, and it
the same problem will also apply to PATCH and PUT and other means of editing
headers. I don't care so much about whether my suggestion becomes
standardized; I just think these problems should be solved, and the
suggestion I provided was the best compromise I could find.

Regards,
Brian

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 30 Apr 2008 02:26:46 +0200

Brian Smith wrote:

> "\d" and "d" mean the same thing according to the definition
> of quoted-string in RFC 2616, AFAICT. We are supposed to
> unescape quoted-strings before processing them, right?

That is a dark corner in the spec.  RFC 2617 specifies unq(X)
as "the value of the quoted-string X without the surrounding
quotes".  RFC 2831 adopted this algorithm in its <qdstr-val>.

I-D 2831bis was about to change it, but the SASL folks later
decided to give up on updating RFC 2831 as hopeless case - an
unfixed erratum in RFC 2617 rendered "md5-sess" in RFC 2831
and RFC 2617 as incompatible, among other Digest-MD5 issues.  

Whatever you do - please be very clear about it, add MUSTard,
a note in the 2616bis security considerations, and recommend
"future work" for a 2617bis based on 2616bis.

 Frank

---

From: Henrik Nordstrom <[email-masked]>
Date: Wed, 30 Apr 2008 02:31:34 +0200

On tis, 2008-04-29 at 11:44 -0700, Brian Smith wrote:

> https://example.org/foo).

This is one of the purposes of Content-Location, tells user agents the
"original/primary" location of this object if it's accessed from a
secondary location.

It's not pushed very hard in the specs as there is nothing that says the
two really has any strict relation to each other. The one giving you
Content-Location may well be lying about it and providing you an
entirely different object than what is available at the Content-Location
specified URI, just as they may make up any other headers such as Link..

Regards
Henrik

---

From: "Brian Smith" <[email-masked]>
Date: Tue, 29 Apr 2008 18:40:18 -0700

Henrik Nordstrom wrote:
> > I would like to see an "Edit" header that allows the server 
> > to say that PUT/DELETE requests should be sent to a different
> > request URI. For example, I want the server to suggest that
> > edit requests for the resource at http://example.org/foo 
> > should be sent to the authenticated URI 

Here are the problems I found with using Content-Location for this:

* Content-Location changes the base URI used to resolve relative URIs. I
don't want to change the base URI for relative URIs because the https://
server has different authentication and caching policies from the http://
server. Plus, many clients get the base URI handling of Content-Location
wrong.

* Section 14.14 of RFC 2616 says "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. Future requests MAY specify the Content-Location URI as the
request-URI if the desire is to identify the source of that particular
entity." I want a header that says "Future requests, except for GET/HEAD
requests, SHOULD/MUST specify the <header-name> URI as the request-URI."
That is a small but very important difference.

* I want to provide an ETag for resource HTTPS://example.org/foo in the
response to a request at HTTP://example.org/foo, so that I can immediately
issue meaningful conditional requests at the HTTPS:// URI. I think it would
make sense for the specification to say that, when a response has an ETag
field and a Content-Location field, the ETag MAY be used for meaningful
conditional requests at the Content-Location URI. But, RFC 2616 doesn't say
that.

Recently I've seen a few discussions regarding Content-Location, where the
definition of Content-Location *almost* seems to do what people want. For
example:

* Julian Reschke's GET-Location header [1]. Roy Fielding and others have
said that Content-Location does the same thing as the proposed
Content-Location header, but after reading RFC 2616 very carefully, I don't
think the current definition of Content-Location is clear enough to draw
that conclusion. 

* If a response to a PUT contains a Content-Location header and/or
Expires/Cache-Control headers and/or an ETag, can we cache that response (to
the PUT) for subsequent GET requests to the Content-Location URI. In
particular, can we do so when the Request-URI is the same as the
Content-Location URI? See [2]. My reading of RFC 2616 is that it explicitly
says we can't do that. However, I'm not sure why not; it seems perfectly
sensible do so, as long as the security considerations are kept in mind.

It would be nice if the specification clearly explained the relationship
between a response with a Content-Location of "X" and requests with a
Request-URI of "X".

[1]
http://greenbytes.de/tech/webdav/draft-reschke-http-get-location-latest.html
[2] http://www.imc.org/atom-protocol/mail-archive/msg10845.html (Be sure to
read the whole thread)

Regards,
Brian

---

From: Henrik Nordstrom <[email-masked]>
Date: Wed, 30 Apr 2008 04:02:06 +0200

On tis, 2008-04-29 at 18:40 -0700, Brian Smith wrote:
> server.

that is a slight difference.

>  Plus, many clients get the base URI handling of Content-Location
> wrong.

True. and as many servers get Content-Location wrong user-agent authors
do not want to implement this proper..

> That is a small but very important difference.

There is no chance to get this specified as a SHOULD/MUST as you still
need to be compatible with eralier clients..

And no matter what you do you will still be battling the same security
issues which holds Content-Location back. See below.

> conditional requests at the Content-Location URI. But, RFC 2616 doesn't say

You may, but there is nothing in HTTP which says that a response from
URI A is authorative for URI B. Content-Location is just a hint, and if
you trust the server and ETag matches it's a fairly good one (about as
good as you can get within HTTP).

> think the current definition of Content-Location is clear enough to draw

It's as close as you can get. But that discussion is a bit muddled up
from the fact that WebDAV doesn't map very well to the HTTP object
model.

> the PUT) for subsequent GET requests to the Content-Location URI.

If a response to PUT has a cache validator you can use that to verify
that there has not been any other edits of the object, but it's not a
guarantee that the resource held by the server matches the entity you
sent in PUT.

> In
> Content-Location URI?

Yes. Or when the two differ. No difference really. But you can not
assume the PUT request entity as authorative for the current state of
the indicated server resource. The only thing you can take as
authorative is the ETag value.

> between a response with a Content-Location of "X" and requests with a

If you request "X" you are supposed to get the same result as you
earlier got with a Content-Location: X, but security concerns says there
is no guarantee this is the case and trivial to fake in many situations
so they MUST NOT be automatically considered equal.

The exact same security concern applies to any Link type header you can
come up with as it's not about the header content or syntax but about
who is authorative for the object at "X".

Because of these concerns the spefications degrade Content-Location a
bit, making it less useful than intended. Perhaps too much but it's
easier to fix those cases than trying to invent a new header for the
same thing and go over the same security concerns and loopholes again.

Regards
Henrik