HTTP Headers vs. link rel=

Mon May 23 09:11:39 PDT 2005

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