HTTP Headers vs. link rel=
bill.rawlinson at gmail.com
Tue May 24 12:27:18 PDT 2005
Brad Fitzpatrick wrote:
>Plus once there are two ways, people will be surprised when their HTML
>(all they can see!) doesn't work, because there are mystery magic HTTP
>So I'd say HTML headers would have to always override the Link header. I
>don't care much about the HEAD request. I figure people can do GET
>requests with byte ranges, asking for the first 1k or 2k. The latest
>version of Net::OpenID::Consumer (unreleased) has to do a GET to get the
>full head and find rss, atom, foaf, foafmaker, etc, which is then
>available from the VerifiedIdentity object.
I really don't have much to add to any of the conversations that have come
up but I did want to interject one thought here.
A couple of days ago, when the idea of the header element was first brought
up I thought someone made a good point concerning the
link and header relationship. Basically, if the user is on a service
provider, (AOL, MSN, whatever) and that host adds an indentity server
header it would be great for all those users who don't really want to worry
about doing it themselves. However, if a user wants to specify a
different server that they actually have control over, then their only real
option is the <link> because of that I think the <link> such supercede
In the end it should be up to the user who verifies them. I would bet MOST
users will never know what an HTTP header is let alone how to set one up.
But, thanks to various places that they already login they may create an
OPENID account that they want to use as their primary identifier and,
subsequently, override the header. Heck, the user probably wont even know
their service provide has the header there. Thus, when their <link> doesn't
work they won't understand, get frustrated, and will probably end up
abandoning the idea of using an OPENID.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the yadis