Subject: draft-nottingham-http-link-header-05: a question and an experimental implementation

From: Michael Burrows <[email-masked]>
Date: Fri, 19 Jun 2009 10:41:41 +0100

I have a question on draft-nottingham-http-link-header-05: is there an
agreed mechanism for clients to indicate whether they want link
headers, the equivalent html/xml elements, or neither?  It seems
wasteful to generate redundant or unneeded data, especially while
client support for the headers is not widespread.   Apologies if this
has been covered previously (I did review the April-June archive).

Meanwhile, you may be interested in an experimental implementation of
link headers (&/or elements) for Ruby on Rails, generating them from
metadata constructed from the application's routing config.  Please
drop me a line if you'd like to play with it.  There is a Python
library too but it lacks the server framework integration.

I went with the hash URI approach [1] to identifying extension
relation types, with the fragment pointing inside the metadata
obtainable (in multiple formats) via the "describedby" links.  See for
example the last two links below:

    Link: <http://example.com/users/dojo>; rel="self"; type="user",
          <http://example.com/described_routes/user>;
rel="describedby"; type="ResourceTemplate",
          <http://example.com/described_routes/user?user_id=dojo>;
rel="describedby"; type="ResourceTemplate",
          <http://example.com/users>; rel="up"; type="users",
          <http://example.com/users/dojo/edit>; rel="edit";
rel="http://example.com/described_routes/user#edit"; type="edit_user",
          <http://example.com/users/dojo/articles>;
rel="http://example.com/described_routes/user#articles";
type="user_articles"

If I interpret the spec correctly, there is no strong guidance on the
use of the "type" attribute.  I hope that my usage here seems
reasonable.

    [1] http://www.w3.org/TR/cooluris/#hashuri

Regards,

Mike
[email-masked]
http://positiveincline.com
http://twitter.com/asplake

---

From: Michael Burrows <[email-masked]>
Date: Tue, 23 Jun 2009 07:32:14 +0100

Re my last paragraph below, I hadn't checked RFC 4287 for a
description of the "type" attribute.  Newbie error, apologies.

With that out of the way, what's the thinking on the duplication of
link elements and link headers?  Are there mechanisms for UAs to
indicate which they prefer?  I've been through a year's worth of
archive now and didn't find this addressed anywhere.

Thanks,
Mike

---

From: Phil Archer <[email-masked]>
Date: Tue, 23 Jun 2009 10:11:17 +0100

Hi Michael,

> archive now and didn't find this addressed anywhere.

I'm not aware of any such mechanisms but it's a point that I've heard 
raised informally. Adding in a bunch of links in the HTTP response to 
every request when they're not required is the kind of thing that gets 
server infrastructure engineers very upset.

However, I don't think there's a need to invent anything new here. 
Cookies could easily be set that indicated that Links had already been 
consumed by a given browser. Of course, that only applies on the second 
and subsequent requests, not the first one, so it doesn't answer all 
your point, but it gets pretty close?

Opera and FF both implement HTTP Link (see [1] for example) but Chrome, 
Safari and IE don't. It's pretty easy therefore to configure a server to 
include HTTP Link for those browsers based simply on the UA string and 
put in the HTML link elements for the others? Again, not a complete 
solution, I know, but a practical way forward?

Cheers

Phil.

[1] http://www.fosi.org/archive/httplinktest/

-- 

Phil Archer
http://philarcher.org/

i-sieve technologies                |      W3C Mobile Web Initiative
Beyond Impressions                  |      www.w3.org/Mobile

---

From: Michael Burrows <[email-masked]>
Date: Thu, 25 Jun 2009 14:27:55 +0100

Thanks Phil, that seems reasonable enough.

For the record (expanded somewhat in [1]), I went with "role" to fix
my erroneous use of "type" and its values are URIs now.  Very much
along the lines of Tim BL's Metadata Architecture note [2] it
generates globally unique identifiers not only for relationships but
also their source and target entities in a logical ER view of the
application, the entities corresponding to the application's templated
"routes".  Moreover those identifiers point ("hash fragment" style)
inside metadata documents.

    [1] http://positiveincline.com/?p=392
    [2] http://www.w3.org/DesignIssues/Metadata.html

Regards,
Mike

2009/6/23 Phil Archer <[email-masked]>:
> I'm not aware of any such mechanisms but it's a point that I've heard raised
> informally. Adding in a bunch of links in the HTTP response to every request
> when they're not required is the kind of thing that gets server
> infrastructure engineers very upset.
>
> However, I don't think there's a need to invent anything new here. Cookies
> could easily be set that indicated that Links had already been consumed by a
> given browser. Of course, that only applies on the second and subsequent
> requests, not the first one, so it doesn't answer all your point, but it
> gets pretty close?
>
> include HTTP Link for those browsers based simply on the UA string and put
> in the HTML link elements for the others? Again, not a complete solution, I
> know, but a practical way forward?
>
> Cheers
>
> Phil.
>

---

From: Michael Burrows <[email-masked]>
Date: Thu, 25 Jun 2009 15:18:28 +0100

Thanks, I'll do that.  I was in contact with Eran some time back (before I
had anything very concrete) in the hope that everything I'm doing was done
already.  It does still seem that I'm breaking some new ground, though
there's back-tracking to be done every time it transpires that I've
overlooked some previous work.  That's the price of trying to do the right
thing I guess!

2009/6/25 Phil Archer <[email-masked]>

> Hi Mike,
>
> That makes sense and, as I guess you know well, there's a module on 'role'
> for XHTML [1].
>
> With all those links, perhaps with additional type="MIME-type" attributes,
> I quite see why you're concerned about shipping so many bytes with every
> request.
>
> You might want to take a look at Mark Nottingham and Eran Hammer-Lahav's
> work in site-meta and discovery at [2] and [3]. These are beginning to look
> a little out of date now but AIUI you'll be able to put all your links in
> the well known location to end all well known locations (actually, I think
> they're now gunning for /well-known) and then put all your links in a text
> file at that location.
>
> Phil.
>
> [1] http://www.w3.org/TR/xhtml-role/
> [2] http://www.mnot.net/drafts/draft-nottingham-site-meta-01.txt
> [2] http://www.ietf.org/internet-drafts/draft-hammer-discovery-03.txt
>
>
> Michael Burrows wrote:
>
>>> raised
>>> Cookies
>>> put

---

From: Phil Archer <[email-masked]>
Date: Thu, 25 Jun 2009 15:00:36 +0100

Hi Mike,

That makes sense and, as I guess you know well, there's a module on 
'role' for XHTML [1].

With all those links, perhaps with additional type="MIME-type" 
attributes, I quite see why you're concerned about shipping so many 
bytes with every request.

You might want to take a look at Mark Nottingham and Eran Hammer-Lahav's 
work in site-meta and discovery at [2] and [3]. These are beginning to 
look a little out of date now but AIUI you'll be able to put all your 
links in the well known location to end all well known locations 
(actually, I think they're now gunning for /well-known) and then put all 
your links in a text file at that location.

Phil.

-- 

Phil Archer
http://philarcher.org/