HTTP Headers vs. link rel=

ydnar ydnar at
Mon May 23 18:03:21 PDT 2005

HTTP headers are nontrivial to edit for some hosting environments, and 
subject to poisoning on the part of the ISP. Parsing the output of a GET 
request as SGML and looking for <head><link rel="openid.server"> is 

TypePad users (certain user levels) can control their own HTML templates. 
Everything from the doctype to </html>. For this user class it would in 
theory make sense to have an HTTP header. But what happens when a page 
specifies a link rel as well? Which one overrides the other?

On Mon, 23 May 2005, Martin Atkins wrote:

> 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:
> > 
> > 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:
>      <>
> 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.
> _______________________________________________
> yadis mailing list
> yadis at

More information about the yadis mailing list