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

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.



Michael Burrows wrote:
> 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]
>     [2]
> Regards,
> Mike
> 2009/6/23 Phil Archer <>:
>> Hi Michael,
>> Michael Burrows wrote:
>>> 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.
>> 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]
>>> 2009/6/19 Michael Burrows <>:
>>>> 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: <>; rel="self"; type="user",
>>>>         <>;
>>>> rel="describedby"; type="ResourceTemplate",
>>>>         <>;
>>>> rel="describedby"; type="ResourceTemplate",
>>>>         <>; rel="up"; type="users",
>>>>         <>; rel="edit";
>>>> rel=""; type="edit_user",
>>>>         <>;
>>>> rel="";
>>>> 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]
>>>> Regards,
>>>> Mike


Phil Archer

i-sieve technologies                |      W3C Mobile Web Initiative
Beyond Impressions                  |

Received on Thursday, 25 June 2009 14:01:22 UTC