HTTP Headers vs. link rel=

Tue May 24 01:17:51 PDT 2005

That's reasonable, provided it's a required part of the spec.

Paul Timmins wrote:

>On Mon, 2005-05-23 at 18:03 -0700, 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?
>>    
>>
>
>What's wrong with allowing an authentication server specified in the
>document to override a server header? That seems like a good way to
>override a bizarre host, while allowing a sitewide auth server if none
>are otherwise specified. This also allows it to be doctype agnostic if
>it wants to be.
>
>I'd use the following logic, in ugly half-perl pseudocode:
>if (serverheader) {
>$authserver=header;
>};
>if (documenthead) {
>$authserver=documenthead;
>};
>
>if ($authserver) {
>print "Authserver is $authserver\n";
>} else {
>print "No authorization server found!\n";
>};
>
>-Paul
>
>  
>