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: Michael Burrows <asplake@freenetname.co.uk>
Date: Fri, 3 Jul 2009 16:01:06 +0100
Message-ID: <7a2269960907030801t3f398ae4h28e96ca48ae543f1@mail.gmail.com>
To: Mark Nottingham <mnot@yahoo-inc.com>
Cc: Phil Archer <phil@philarcher.org>, ietf-http-wg@w3.org
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
>
>
>
>
Received on Friday, 3 July 2009 15:01:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:07 GMT