HTTP Headers vs. link rel=

Mon May 23 09:48:28 PDT 2005

> 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?
> Check out this thread, if you missed it:
> http://lists.danga.com/pipermail/yadis/2005-May/000094.html

Yeah, I'd read that.  The problem there really boils down to "I don't
want to view the blog, I just want metadata about it," for which HTTP
really doesn't provide a good mechanism.  Technically HTTP/1.1 does
not constrain the methods, so one *could* send, say:

    META /users/brad/ HTTP/1.1
    Host: www.livejournal.com

You could reply with all of the metadata associated with that URL.
But that would, in effect, notate the logs properly and allow for a
specific key for the server to catch.  The result could be an XML file
with all associated metadata, not just limited to the openid.server.

But then we're in the realm of proposing new HTTP verbs, which is
tricky business any way you slice it, and it replaces one problem
(parsing questionable HTML) with another (parsing questionable XML).
Returning the openid.server in the headers is still a possibility even
in this case.

> Well, we can update the <head> section of people's journals without
> touching any templates.  But I see your point in general.

Yeah -- LiveJournal can do something like that.  On Diary-X,
Diaryland, etc, where free users can supply their own templates,
though, we'd have to provide more code on the backend to pull out the
<head> section and add the link tag, or rely on the user to correctly
add the tag.  Not impossible, but certainly more complex than just
pushing another header out.  Also, we'd have to deal with malformed
code from HTML neophytes.

> So most client libraries will end up doing two hits, since most servers
> won't send the X- header.  (playing the pessimist)

Now that I'm thinking more about the issue, maybe HEAD isn't a good
choice.  For dynamic sites, the content would have to be hit anyway to
determine whether or not it's been modified (in case the HEAD is a
real HEAD request), and in order to produce the full headers the
entire content would have to be generated in order to be measured for
Content-Length.

Forget I said anything about HEAD.  My other points still stand.  ;)

--sjd;