HTTP Headers vs. link rel=
brad at danga.com
Mon May 23 09:11:39 PDT 2005
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
> 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
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)
Check out this thread, if you missed it:
More information about the yadis