[OpenID] "303 See Other" should not change Claimed ID

[Manger, James H]

An HTTP 303 "See Other" response code during discovery should not
change the claimed id.

Currently, any redirect during normalization/discovery changes
the OpenID URL (the claimed id). Previous discussion considered
treating permanent and temporary redirects differently (301 vs 302/307).
[http://openid.net/pipermail/general/2007-January/000946.html]

Permanent and temporary redirects (301 & 302/307) should be treated
the same way -- ie change the claimed id (as in the current spec).
Their difference is a matter of timing (always vs just for a while),
not of semantics. In both cases the identify is being switched to
another URI. You should be able to do this for 1 minute, 1 week or
forever.

A 303 "See Other", however, explicitly has different semantics.
The HTTP 1.1 spec [RFC 2616] says (with my emphasis):
 “10.3.4  303 See Other
  The response to the request can be found under a different URI
  and SHOULD be retrieved using a GET…
  The new URI is NOT A SUBSTITUE REFERENCE for the
  originally requested resource.”

Alternatively, as described in RESTful Web Services:
303 "See Other": The request HAS been processed…
307 "Temporary Redirect": The request has NOT been processed…

Consequently, a 303 should be usable to indicate where a Yadis (or HTML)
document can be collected from, without changing the claimed id.

Theoretically, this is not a backwardly compatible change.
In practise, however, I suspect very few (if any) “name providers”
currently use a 303. OpenID is inconsistent with HTTP in handling
303, which this change would fix.

People want to use the proper 303 semantics (not change the claimed id).
Sam Ruby though that was what he was getting when he issued a redirect
on seeing “Accept: application/xrds+xml”.
 “let me start out with what I consider the best way [to be]:
  redirectng requests based on the value of the HTTP accept header”
[http://www.intertwingly.net/blog/2007/01/03/OpenID-for-non-SuperUsers]
Sam likes a redirect (that is not totally necessary) so
1) it shows up in his access logs;
2) to avoid pitfalls with content negotiation.
Note: Sam’s post is prominently linked from openid.net/developers/ page.



[P.S. Any chance of fixing http://openid.net/pipermail/ so it does not
wrap emails in <PRE>. Changing any [CR] LF to <br/> is fine, but <PRE>
makes plain/text email unreadable when it only uses line feeds to
separate paragraphs -- you get single lines that scroll 10 screens to
the right!]