[OpenID] Temporarily redirecting one's identity?

Martin Atkins 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: 
> http://www.intertwingly.net/blog/2007/01/03/OpenID-for-non-SuperUsers
> 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://www.livejournal.com/users/frank/ becomes 
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
Content-type: text/html
X-XRDS-Location: http://intertwingly.net/public/yadis.xrdf
Vary: Content-type

<p><a href="http://intertwingly.net/public/yadis.xrdf">XRDS Document</a></p>

I will admit that this is ugly[1], 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"[2] 
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.


[1] 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 
text/html document!

[2] 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 mailing list