W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2008

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

From: Brian Smith <brian@briansmith.org>
Date: Tue, 29 Apr 2008 11:44:51 -0700
To: "'HTTP Working Group'" <ietf-http-wg@w3.org>
Cc: "'Mark Nottingham'" <mnot@mnot.net>
Message-ID: <000d01c8aa29$1ca16760$0202a8c0@T60>

From: Mark Nottingham [mailto:mnot@mnot.net] 
> 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

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

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

Received on Tuesday, 29 April 2008 18:45:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:45 UTC