On 19/03/2008, Noah Slater <[EMAIL PROTECTED]> wrote: > On Wed, Mar 19, 2008 at 08:43:46PM +0900, James Henstridge wrote: > > > Given two backwards incompatible changes I hardly see how one which > breaks > > > existing OpenIDs is favourable to one which changes how some are > handled. > > > > That seems to be an argument for making no changes. > > > No, it's an argument to make the backwards incompatible change that effects > people in the smallest possible negative way. Your suggestion replaces one > non-compliant usage of HTTP with another, which is hardly a step forward. > > > > You're okay with sites interpreting your ID differently depending on > > the version of OpenID they support? Aren't you concerned that you'll > > lose access to your accounts on various RPs if your OP or the RP > > upgrades? Or do you planning to only talk to RPs that support the new > > version? > > > They already do this. > > cf. http://chatlogs.planetrdf.com/swig/2008-03-10.html#T16-58-17
Your comment from that page is: <nslater> So, on one site I am <http://bytesexual.org/about/>, on another I am <http://bytesexual.org/> and on one I was </about/>! The fact that some sites incorrectly resolved the redirect to "/about/" is probably due to the non-standard response headers for http://bytesexual.org/ -- it contains a relative URI reference in the location header, while the spec requires an absolute URI. Do you have more information about which sites exhibit which behaviour? Or better yet, which libraries they are using? > > I also don't think that such a decision should be based on your assertion > that > > you're the only one who would be affected. > > > I wasn't really making an assertion, more a jocular suggestion that this is > probably not very widespread, so it would be nice to fix it now while we can. > > > > To maintain compatibility with existing versions of OpenID, RPs would > > need to perform discovery, and then decide which of two identity URLs > > to use based on which protocol version is negotiated. > > > Again, strictly this is true, but given the woeful implementations we have at > the moment (see above reference) I really can't see that this would happen. You wouldn't get quite so much variability if you included an absolute URI in the location header. It sounds like you'd still see some though, but it isn't clear what proportion are not conformant. > > Whatever you might say about the existing discovery mechanism, this > > does seem a lot more complex, since it intermingles discovery with > > protocol version negotiation. > > > Sure, it might be a bit more complex, but that is not an objective technical > argument for ignoring the low level HTTP semantics. > > > > Perhaps it'd help if you described exactly what your use case is. > > > cf. http://openid.net/pipermail/general/2008-March/004362.html That use case sounds like it'd be covered by the solution I outlined below. > > If you want to have an identity URL which is used as is by OpenID RPs > > doing discovery but have web browsers redirected to another URL, have > > you considered using <meta http-equiv="Refresh" ...> instead of a 303 > > redirect? This should have the desired effect with OpenID 1, 2 and > > any future versions. > > > I am using 303 redirects for the explicit semantics this affords under the > TAG's > httpRange-24 resolution, and so a http-equiv meta element would not work. > > cf. Dereferencing HTTP URIs, 4.1 Using HTTP to Represent Associations > > http://www.w3.org/2001/tag/doc/httpRange-14/2007-05-31/HttpRange-14.html The opening text of the document is: """ This document is an editors' copy that has no official standing. In particular, it does not yet necessarily reflect consenus within the working group or within the wider community. """ So this isn't quite the binding standard you're making it out to be. As far as standards go, the HTTP 1.1 RFC describes the 303 response as existing primarily for use with POST requests. So the phrase "The new URI is not a substitute reference for the originally requested resource" needs to be interpreted in the context of how POST interacts with other 30x status codes. It doesn't offer any guidance on when it is appropriate to use in response to a GET request. James. _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
