Proposal: consumer sends special openid.server discovery header URL/arg

[Martin Atkins]

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
> proxies.
> 
> 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.
> 
> Either:
> 
> 1) New URL argument:
[snip]
> 2) New HTTP header:
[snip]

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:
     Vary: whatever-header
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.