HTTP Headers vs. link rel=
mart at degeneration.co.uk
Tue May 24 00:14:11 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?
If your hosting provider is "poisoning" your content, then you need to
get a better hosting provider since they obviously cannot be trusted.
Even if the hosting provider does do something like this, presumably
they will then vouch for the URL, which doesn't really have any negative
result unless they start rejecting identity requests outright. If they
provide a working identity server, then you get validated as being the
owner of that URL just as you would have done anyway.
We already discussed multiple LINK elements and decided that the
consumer is free to pick any one. I don't see why this is any different.
The consumer can decide which one beats what depending on the
relationships it has with all of the listed servers. They should all work.
The main reason *I* proposed allowing a header was to avoid tying OpenID
to a particular document format. The ability to optimise to using HEAD
to make the request is a nice side-effect, but not one I care a great
More information about the yadis