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

The cookie strategy (or anything like it) isn't good for caching or  

I think -- as in many things -- this requires a judgement call by the  
author. If you're slinging around hundreds of links on every response,  
there's a good chance that you're doing something wrong; odds are that  
most of the links will be irrelevant to most use cases. Refactoring  
into separate representations, etc. makes sense here.

In this way, it's no different to deciding what is at the other end of  
a URL; too fine-grained, and it's not useful, but too coarse-grained  
and you're giving too much information and overloading the  
infrastructure. Of course, what the infrastructure can take changes  
over time too.


On 23/06/2009, at 7:11 PM, Phil Archer wrote:

> 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                  |

Mark Nottingham

Received on Thursday, 2 July 2009 23:27:43 UTC