[OpenID] Only 303, not temp redirects (302/307), need changing
John Panzer
jpanzer at acm.org
Fri Mar 7 16:26:11 UTC 2008
I can see merits in various sides of this debate. I'd like to throw a
few observations in:
1. OpenID is a mechanism for proving effective control over a URI.
2. A URI doesn't need to point at a web page which returns HTML...
3. ...but it almost always does, and so there are potential conflicts
between using the URI to point at a web page and using it as an OpenID.
In other words, OpenID is _not_ free in practical terms to completely
redefine HTTP response codes to suit its semantics, unless it wants to
risk collisions with reasonable web page setups, such as:
A. Sam Ruby's 303 See Other in response to an XRDS metadata request,
purely for convenience of implementation.
B. Redirecting from an insecure protocol to a secure one, necessary
because OpenID rules demand that reasonable human-entered strings use an
insecure protocol by default (for good reason).
C. When the underlying resource itself moves homes, perhaps to a new
service provider, leaving a redirect (301, probably) for a while,
ideally followed in a few months by 410 Gone Buh Bye but practically
that's not guaranteed.
I personally would probably become happy around any decision on
semantics of 3xx codes, as long as the above scenarios are handled
reasonably (from the POV of the end user) and we have _some_ way to keep
an RP from throwing away what the user entered in their UI in favor of
https://zx3838.example.org/cgi-bin?openid-xrds-resolver&k1=38838s838
because that was the convenient way for the OP's site admin to set
things up.
John
More information about the general
mailing list