HTTP Headers vs. link rel=

Tue May 24 00:14:11 PDT 2005

ydnar wrote:
> 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 
> trivial.
> 
> 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 
deal about.