Proposal: consumer sends special openid.server discovery header
mart at degeneration.co.uk
Fri May 20 01:55:16 PDT 2005
Brad Fitzpatrick wrote:
> Big sites (say, LiveJournal) have many layers of HTTP proxies and servers.
> Anything that can stop a request early and not pass it down to lower
> layers is great.
> For example, our userpic URLs never change, so if we see a
> If-Modified-Since request on any of them, our upstream load balancers can
> reply with a not modified and avoid about 3 or more layers of servers and
> With all the auto-discovery of openid.server <link> tags that will
> be happening, I'd like the major players (both consumers and servers) to
> agree on one of the following two "hints" that the GET request being made
> is only being done to get the openid.server value.
> 1) New URL argument:
> 2) New HTTP header:
I don't really like either of those options, but I'd pick 1) if I had to
choose, for the reasons you state. People would forget to use the
no-cache directive, and in most cases it'll be fine but then there'll be
some weird case where for some reason a consumer (or a non-browser
client, more likely) makes a request through a shared proxy and it'll
screw everything up.
> 3) Accept:, Accept-Language: ? Both don't feel exactly right, but at
> least it'd be closer to a spec.
I can't think of any way to apply these, since the server will be
returning (most probably) text/html anyway, and the language is
irrelevant. Even in this case the server must return:
to clue the proxies in that changing that field will change the
response. Even then, I bet there are proxies which ignore that field.
The whole idea seems like yet another giant hack, but I see the
sentiment behind it. Really, it seems like it should be LiveJournal that
solves this problem, not OpenID. I hope someone comes up with a better
way, but I don't have one.
More information about the yadis