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

From: Mark Nottingham <[email-masked]>
Date: Fri, 3 Jul 2009 09:24:37 +1000

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

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.

Cheers,

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] http://www.fosi.org/archive/httplinktest/
>
>
>> 2009/6/19 Michael Burrows <[email-masked]>:
>>> 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
>>>
>
> -- 
>
> Phil Archer
> http://philarcher.org/
>
> i-sieve technologies                |      W3C Mobile Web Initiative
> Beyond Impressions                  |      www.w3.org/Mobile
>

--
Mark Nottingham       [email-masked]

---

From: Michael Burrows <[email-masked]>
Date: Fri, 3 Jul 2009 16:01:06 +0100

2009/7/3 Mark Nottingham <[email-masked]>:
> The cookie strategy (or anything like it) isn't good for caching or scaling.

That concerns me too. I may have to accept that most clients won't be
interested in links, and let them specify explicitly (perhaps by a
query parameter) which ones they need.

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

I would agree.  Certainly not hundreds of links ; generally just a
handful, perhaps a few more on top level landing sites.  Anyone
wanting the template for the whole site can get that separately.

>
> 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.
>
> Cheers,

Regards,
Mike

>> 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.
>>
>>>> I have a question on draft-nottingham-http-link-header-05: is there an
>>>> client support for the headers is not widespread.   Apologies if this
>>>> Meanwhile, you may be interested in an experimental implementation of
>>>> obtainable (in multiple formats) via the "describedby" links.  See for
>>>> rel="http://example.com/described_routes/user#edit"; type="edit_user",
>>>> If I interpret the spec correctly, there is no strong guidance on the

---

From: Phil Archer <[email-masked]>
Date: Fri, 03 Jul 2009 16:15:22 +0100

Incidentally, there's now an HTTP link from http://www.w3.org/Mobile/ 
which points to the POWDER file that describes the page as being 
mobileOK. See the headers at http://tinyurl.com/npybzg

Phil.

-- 

Phil Archer
http://philarcher.org/

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