HTTP Headers vs. link rel=

[Martin Atkins]

Stephen Deken wrote:
> Hello all,
> 
> Instead of parsing for the <link rel="..."> tag, would it be possible
> to amend the spec to use an HTTP header instead?  Something like:
> 
>   X-OpenID-Server: http://www.livejournal.com/auth/?type=openid
> 
> The semantics would be the same as for the <link rel="..."> tag, but
> it would take precedence over it if it were present.  Ideally, this
> method would be the preferred method.  Advantages:
> 
>   1. Easier to parse; headers are well understood
>   2. For 'hive' sites such as LiveJournal the header could be
> mandated, allowing all users to use the functionality without needing
> to update their templates to include the link
>   3. It would be possible to use a HEAD request instead of a GET,
> allowing the server to not produce content for no reason, saving
> bandwidth
> 
> If the HEAD request does not yield the desired header, a GET request
> could be issued and parsing could occur as it does right now.
> 
> Thoughts?
> 

An HTTP header in addition to the HTML link was one of my first proposals:
     <http://lists.danga.com/pipermail/yadis/2005-May/000032.html>

I wasn't proposing it for the same purpose you are, but this seems like 
a good reason too. The "Link" header can also include FOAF/other 
autodiscovery stuff, as it's semantically equivilent to HTML's LINK element.

We already had some discussion about people specifying multiple identity 
servers and just letting the consumer pick whichever it wants, and a 
consumer giving preference to one specified in the header would be 
consistant with the "do whatever you want" policy.

If we are to go this route, I'd rather use the general "Link" header 
than invent a new one. It's not a standard, but it's specified well 
enough that it's not likely to change and it supports everything that 
HTML's LINK element does.