HTTP Headers vs. link rel=
ydnar at shaderlab.com
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: 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:
> 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 lists.danga.com
More information about the yadis