mark nottingham

Bringing Back the Link - With a Twist

Thursday, 22 June 2006


Recently, there’s been a resurgence for the Link element in HTML; everything from Microformats to Atom autodiscovery is using it. This isn’t surprising; as machines start processing Web documents more, it’s necessary to use hyperlinks — the foundation of the Web — to tie resources together, without getting in users’ faces.

Such linking is useful beyond HTML, of course; Atom defines its own concept of link relationships, and uses them in the Atom Publishing Protocol.

Usually, embedding this kind of link in the content is enough, because the software processing the content is also the software that needs to know about the link. Sometimes, however, that isn’t the case. For example, if we want to discover a link to site-wide metadata of some sort, it might be necessary to give that information to a completely different piece of software that doesn’t know anything about that format. While the metadata can be extracted and sent on, that can be tedious, error-prone, and makes it hard to layer software properly.

What’s the best way to do that? While we could mint a new HTTP header for your link, doing so properly isn’t a small undertaking, and it’s likely that everyone would have to write parsers and serialisers just for its idiosyncracities (just as they would if every new link in HTML and Atom required a new element).

Instead, it would be great if there were something analogous to the Link element in HTTP headers.

What’s Old Is New Again

RFC2068 actually did that; it documented the Link HTTP header in an appendix, but by the time RFC2616 rolled around, it was gone because no-one was using it at the time. While it’s perfectly fine to use the Link header today (it’s in the registry), its disappearance confused some people, and led them to believe that they couldn’t.

To this end, I’ve submitted an Internet-Draft to re-define the Link header, just as it was before. Additionally, the draft defines a Profile header, to serve the same function as the profile attribute in HTML.

But wait, there’s more. Templated links are very useful for building protocols dynamically, without breaking URI opacity. For example, WebDAV defined a whole new method to discover metadata (PROPFIND), when it could have just defined a URI for it, if sites had an efficient way of communicating how to build one.

Link templates do that. For example;

Link-Template: <{userid}>; rel="home"

tells the receiver of the message that they can figure out anybody’s home URI, given their userid.

I actually have a lot more use cases for this, but they’re going to stay under my hat… for now. For now, I’ll point out that once you have URIs as first-class, typed citizens in HTTP headers, some Semantic Web tools look a lot more interesting. It also becomes easier to extend HTTP in Web-friendly ways.

Comments? Suggestions? Send them to me directly, or to the HTTP mailing list.


James Snell said:

Hey Mark, DeWitt Clinton and I have been kicking some stuff around in the URI templating space. I’ve documented some thoughts on my personal blog @

Thursday, June 22 2006 at 11:39 AM

Damian Cugley said:

+1 for reinstating Link headers.

As well as Link I would like to see Title brought back. This would magically allow a slideshow to be made from JPEG files with no HTML at all: the server would dish them up with Title and Link headers and the browser’s own link-aware navigation would do the rest. :-)

I think this falls under the list of things HTTP was designed to support in 1993 or whenever that no-one has actually implemented properly yet. Sigh.

Friday, June 23 2006 at 5:30 AM

Mark Baker said:

For URI templating, could we not associate a variable with a URI? There’s an awful lot of potential variable names, so I think it’s warranted in this case.

FWIW, I did that with RDF Forms; declared a “short name” for use in the constructed URI, which was just an alias for a URI.

As for a mechanism, I suppose you could shove it on the end of the Link-Template header, ala;

Link-Template: ; rel=”home”; userid=””

which rules out rel & rev for variable names, but seems simple and intuitive. Then again, using a new header would permit reuse of that information for multiple templates, if you think that might be a common case. Dunno. You’re the guy with the secret plans. 8-)

Friday, June 23 2006 at 7:48 AM

Mark Baker said:

I see, but that brings up another issue. With typical forms, the only URI you see is an actual URI - one you can invoke GET on, say, to find the description of how to parameterize the URI. With templating you don’t get that; you get something that looks like a URI (matches the generic production), but it’s not really a URI because it doesn’t identify anything, and you can’t invoke GET on it.

It’s not a deal-breaker, and I do like the compactness of a template. Just saying…

Sunday, June 25 2006 at 12:12 PM

Dan Connolly said:

We need the Link and Profile headers for GRDDL; see issue-http-header-links.

I notice the Internet Draft has expired.

Please renew it, and please ask whatever gods are necessary to get Profile registered, at least provisionally. Danny A. sent you mail about this 8 Feb.

I see you’re moving country, so I’m using this redundant channel in case it helps.

p.s. I hate ; please allow links from comments.

Saturday, February 17 2007 at 5:30 AM