HTTP Headers vs. link rel=

Mon May 23 09:34:43 PDT 2005

I could see doing a GET request to get the HTTP headers as well as the 
document, and then look for an X-OpenID-Server in the HTTP headers. The 
client could ignore the document, and rely on the headers.

The problem with this approach is that ISPs or hosts could poison the 
OpenID system, rendering it useless, by including a bogus 
X-OpenID-Server header.

For example, AOL could "poison" the homepages of its users with an 
X-OpenID-Server header that points to an AOL-owned OpenID server. So 
even if the user put a link rel to LiveJournal in his index.html, the 
OpenID client would ignore that and instead go for the HTTP header.

Control over page HTML is more common than control over HTTP headers, 
which require extra software to view anyway. If someone can't be arsed 
to generate a parsable <head> then they've got bigger problems anyway.

y

Brad Fitzpatrick wrote:

>Stephen,
>
>On Mon, 23 May 2005, 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
>>    
>>
>
>Mart and I were discussing this the other day, but in the opposite
>direction:  how can a consumer library signal to the webserver that all it
>wants is the openid.server?
>
>I hadn't considered HEAD.  The problem with HEAD, though, is that the
>consumer library will likely also want to fetch the entire <head> at the
>same time (not just the HTTP headers), so it learns about FOAF/hCARD/etc
>files that are under the claimed identity URL root.
>
>  
>
>>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
>>    
>>
>
>Agreed.
>
>  
>
>>  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
>>    
>>
>
>Well, we can update the <head> section of people's journals without
>touching any templates.  But I see your point in general.
>
>  
>
>>  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
>>    
>>
>
>And then the problem of not getting FOAF/etc knowledge.
>
>  
>
>>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.
>>    
>>
>
>So most client libraries will end up doing two hits, since most servers
>won't send the X- header.  (playing the pessimist)
>
>  
>
>>Thoughts?
>>    
>>
>
>Check out this thread, if you missed it:
>http://lists.danga.com/pipermail/yadis/2005-May/000094.html
>
>- Brad
>
>_______________________________________________
>yadis mailing list
>yadis at lists.danga.com
>http://lists.danga.com/mailman/listinfo/yadis
>
>  
>