As confusing as HTTP redirect semantics might be, I am confident that you will not find anyone that deliberately chooses to return a 303 See Other without explicitly wanting to keep the original URL as the "identity" and the new URL as merely a (stable, cachable) location for the current response (eg current OP details). I am confident this will be true for any web content, not just OpenID.
[Aside: Browsers displaying the new URL in the address bar after a 303 See Other is not a counter-example. The new URL is the address of the displayed response. It is NOT the address that will be reused if the original request (eg an HTML form submission) is retried.] The ability to serve discovery details from a location that is different from the claimed_id is desired functionality: 1* You can achieve it using X-XRDS-Location (HTTP header or <meta> element), but only if you deliver other content (eg HTML) at the claimed_id; 2* You can achieve it using an i-name (by the abstract nature of those ids and the various synonyms explicitly defined for those ids); 3* You can achieve it via "directed identity" if your OP cooperates, and with a very extra request/response pairs; 4* You CANNOT achieve it using standard HTTP (with 303 See Other). The question is whether OpenID wants to bother supporting #4. In adding support for XRI/XRDS/i-names OpenID 2.0 made HTTP URIs somewhat second-class citizens by offering some functionality only when XRI/XRDS is used, even when sensible HTTP mechanisms were also available. Two examples are: supporting X-XRDS-Location but not 303 See Other; and indicating an OP Identifier with a special XRDS <Type>, but not with a special openid2.identifier value. For a true-believer in i-names, not offering an HTTP-way for some functionality is not important (perhaps even helpful for promoting i-names). For a true-believer in HTTP (less enthused by i-names), the lack of an HTTP-way is a problem. Kevin Turner said: "Amend the specification to say: A request for an OpenID Identifier SHALL NOT issue a 303 response." Thankyou Kevin, for a lateral "solution". It is not the fix I want (proper HTTP-style support for 303 See Other), but at least it explicitly tells people that OpenID 2 does not support 303 semantics. That should allow proper 303 support to be added later without big backward compatibility issues. [Aside: In practice, OpenID RP libraries would probably not be changed to explicitly reject 303s -- particularly as your major argument is that that sort of change makes the code too complex. Rejecting or interpreting 303s both require explicitly handling redirect codes, as opposed to setting the "follow redirects automatically" option of the HTTP client library.] Objections to proper support for 303s don't say the proposal is wrong. They just imply it is not worth the effort: "code too complex", "do not have to obey HTTP", "work arounds available", "2.0 is finished". Not surprisingly, these judgements are not convincing to some HTTP true-believers. Perhaps I will add a note to the OpenID 2.0 errata page stating HTTP 303 See Other semantics are not currently supported so they should be avoided when hosting OpenIDs. _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs