Re: Reviving HTTP Header Linking: Some code and use-cases

Brian Smith wrote:
> Julian Reschke wrote:
>> Brian Smith wrote:
>>> Still, nobody has justified why a registry of link relations is 
>>> necessary for the Link header. If you are going to register a link
>> To avoid relation name collisions?
>>
>>> relation, you are better off just making a new HTTP header 
>> that works 
>>> like all the other link headers in HTTP (e.g. Location, 
>>> Content-Location).
>> Besides avoiding having too many HTTP headers?
> 
> That is a bogus argument. As Roy said earlier in the thread, "the link
> relationship space is supposed to be small, universal, and standardized
> (just like HTTP methods)." Besides, is somebody going to be able to able
> to register a link relation with the same name as a registered HTTP
> header, or vice versa? It would be nonsense to register a
> "Content-Location" link relation. If somebody registers an "next" link
> relation, it would be very confusing to then allow someone else to
> register an "next" HTTP header with totally different semantics. So,
> effectively HTTP link relations and HTTP headers share the same
> namespace.

Well, you may wish they did, but they don't.

With Atom relations, we already have name collisions with HTTP header 
("Via").

> As far as I understand the LINK and UNLINK methods, they exist soley to
> edit "Link:" header field values. But, why have a method that can only
> edit one header field, when we could have a method that allows for the
> editing of any header for a resource? Roy already said that PATCH is
> supposed to have that ability. Once you have that method, the need for
> LINK and UNLINK goes away, which also reduces the need for the Link
> header.

I'm not going to defend LINK and UNLINK here; in particular as long as 
we don't get Link: fixed.

>> One reason is that in (X)HTML, you will need a link relation 
>> to include the information into the document. So it seems to 
>> be a better design to have the same mechanism both at 
>> document and transport level, in particular when it already 
>> is specified that way in HTML 4.01 and the proposed standard 
>> of HTTP/1.1 (which is RFC 2068).
> 
> I would agree, except that Roy already said that the semantics for HTTP
> links do not have to match the semantics defined by Atom (or HTML, I
> presume) for any link relation. And, the syntax has to be different from

RFC 2068 says:

"The Link field is semantically equivalent to the <LINK> element in 
HTML.[5]" -- <http://tools.ietf.org/html/rfc2068#section-19.6.2>

...so I don't see how we can change that without rewriting history.

> one of them, because Atom link relations are case-sensitive and HTML
> link relations are case-insensitive. So, we would end up with something
> where the syntax is similar-but-different and the semantics are
> similar-but-different. So, it is not really "the same mechanism" at all.

...which would be an argument not to consider compatibility with Atom.

>>> There must be some miscommunication here. My point is that the Atom 
>>> way of having two forms of each registered link relation is more 
>>> complicated than necessary, offers no real benefits, and should be 
>>> avoided. The easiest way to avoid it is to just not have a 
>>> registry at all. Barring that, at least make the rules for parsing
>>> link relations simpler than the Atom rules.
>> I fail to see how this is a problem in practice:
>>
>> - reject references that are not simple names
>> - then resolve against the base URI
> 
> Let's say you want to check for an "edit" link. It would be simpler to
> only need to either check if that the relation is "edit" or check that
> it is "http://www.iana.org/assignments/link-relations/edit", instead of
> always having to check for both. Already, some (many? most?) Atom
> implementations fail to understand the longer form, so it is already an
> interoperability issue for Atom. 

Well, if you do what the spec says, you don't need to check for both. 
Resolve first, then compare.

And yes, it's always a problem when there are two ways to do the same 
thing. We need test cases for things like that.

> ...

BR, Julian

Received on Thursday, 13 March 2008 13:25:11 UTC