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

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

From: Phil Archer <phil@philarcher.org>
Date: Tue, 23 Jun 2009 10:11:17 +0100
Message-ID: <4A409C35.8040502@philarcher.org>
To: mjb@asplake.co.uk
CC: ietf-http-wg@w3.org
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?



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

> 2009/6/19 Michael Burrows <asplake@googlemail.com>:
>> 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
>> mjb@asplake.co.uk
>> http://positiveincline.com
>> http://twitter.com/asplake


Phil Archer

i-sieve technologies                |      W3C Mobile Web Initiative
Beyond Impressions                  |      www.w3.org/Mobile
Received on Tuesday, 23 June 2009 09:12:03 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:19 UTC