[OpenID] Temporarily redirecting one's identity?
mart at degeneration.co.uk
Thu Jan 4 19:26:57 UTC 2007
Sam Ruby wrote:
> Oh, dear. I may have found an edge case. And documented it in a manner
> that others may follow.
> The documentation is here:
> The issue is that when somebody requests http://intertwingly.net/blog/
> and specifies an Accept: application/xrds+xml header on the request, I
> do a temporary 302 redirect to http://intertwingly.net/public/yadis.xrdf
> The question is: when the identity validation is done, what should the
> RP view as my identity? The original URI (.../blog/) or the "temporary"
> one (.../yadis.xrdf)?
> LiveJournal (http://www.livejournal.com/openid/) choses the former.
> JanRain (http://www.openidenabled.com/resources/openid-test/checkup)
> choses the latter.
> IMO, independent of whether or not I should be doing the redirect, the
> spec should be clear and one or both of these implementations should be
> changed to conform.
> My two cents is that the answer should depend on whether it was a
> permanent redirect (301) or a temporary redirect (302) which was employed.
> However, if consensus forms on this mailing list, I'll update my
> tutorial accordingly.
I believe that the spec doesn't make any distinction between permanent
and temporary redirects: any kind of redirect serves as a
"canonicalization step" (so, for example,
http://frank.livejournal.com/) and so the ultimate destination URL is
used as the claimed identifier. (In other words, LiveJournal is "wrong".)
I admit that this is a bit irritating, but here's a workaround. Rather
than issuing a redirect, you can instead issue a response like this:
HTTP/1.1 200 OK
<p><a href="http://intertwingly.net/public/yadis.xrdf">XRDS Document</a></p>
I will admit that this is ugly, but it should work with OpenID/Yadis
implementations in the wild today.
I don't remember the reason why a temporary redirect was made equivalent
to a permanent one, but this was discussed on a previous occasion.
Perhaps someone can dig up the relevant thread in the archives.
At this point we probably can't make this change due to existing
implementations (though admittedly they do seem to be inconsistent right
now), so perhaps we could instead use a "307 Temporary Redirect"
response and retain the existing meaning of 301 and 302. I note that
Apache's Redirect directive *is* able to generate this response code.
However, I fear that existing implementations might fail when faced with
this previously-undefined response code. Yadis is already "finished", so
it might be too late to add this in now.
 Not least because the client said Accept: application/xrds+xml and
we returned a 200 OK (rather than a 406 Not Acceptable) but sent them a
 I'm not sure from the HTTP/1.1 spec whether I've got the semantics
of 307 correct, but it basically seems to be an alternative to 302 Found
which unambiguously says "repeat that request at this new URL", rather
than 302 which in most browsers is implemented as "Do a GET request on
this new URL instead of whatever you were doing before."
Legacy UAs don't understand the 307 code, but that's okay because only
Yadis clients are going to find this response useful anyway.
More information about the general