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

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

From: Phil Archer <phil@philarcher.org>
Date: Fri, 03 Jul 2009 16:15:22 +0100
Message-ID: <4A4E208A.9040304@philarcher.org>
To: mjb@asplake.co.uk
CC: Mark Nottingham <mnot@yahoo-inc.com>, ietf-http-wg@w3.org
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


Michael Burrows wrote:
> 2009/7/3 Mark Nottingham <mnot@yahoo-inc.com>:
>> 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.
>> 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.
> 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
>> 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 <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
>>> http://philarcher.org/
>>> i-sieve technologies                |      W3C Mobile Web Initiative
>>> Beyond Impressions                  |      www.w3.org/Mobile
>> --
>> Mark Nottingham       mnot@yahoo-inc.com


Phil Archer

i-sieve technologies                   |      W3C Mobile Web Initiative
Sentiment Analysis Beyond Impressions  |      www.w3.org/Mobile
Received on Friday, 3 July 2009 15:16:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:50 UTC