On 19/03/2008, Noah Slater <[EMAIL PROTECTED]> wrote: > On Tue, Mar 18, 2008 at 07:54:20PM -0700, Kevin Turner wrote: > > A request for an OpenID Identifier SHALL NOT issue a 303 response. > > > This is even worse and also backwards incompatible. All the OpenIDs that > currently use 303 redirects, including mine, will all break. > > 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. > > The change you are proposing is not backwards compatible -- an RP that's > > decided your identifier is example.com/about would then decide it's > > example.com/ as soon as it upgrades to the new version, and that > > wouldn't be good for existing users. > > > I think it should behove the OpenID group to actually estimate how many people > might be using 303 redirects in conjunction with an OpenID such as I am > before > concluding that the change should not be made. > > I have a sneaking suspicion that I may be the only person. > > If that is that case, I am happy to inform you that I don't mind the change. 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? 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. > > The XRDS-resolution-for-HTTP-identifiers (nee Yadis) already provides a > > mechanism to publish discovery information at a URL which does not have > > HTML content. > > > Sure, but that doesn't help me and my use case. > > > > The code path you are are requiring the implementations to change > > (OpenID discovery and normalization) is, with the combination of > > different identifier types, protocol versions, and discovery schemes, > > already one of the most tangled chunks of code involved. I acknowledge > > that your proposed change, in isolation, seems simple enough, but that > > code *really* doesn't need another branching condition in it. > > > Arguing the complexity of the implementation is just wand waving without some > concrete evidence to suggest that this would be a complex change. > > Most HTTP libraries should offer simple hooks into the redirect chain. 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. Whatever you might say about the existing discovery mechanism, this does seem a lot more complex, since it intermingles discovery with protocol version negotiation. > > I appreciate the spirit of your suggestion. It's a terrible thing to > > say "oh, we follow standard X, except in the cases outlined in appendix > > B, which you will have to modify your X-implementation to be aware of." > > But, practically speaking, the use case is not compelling enough to > > overcome the cost of change. > > > Again, I don't think you have provided any specifics about the cost of change. > > We don't know how many people use 303 redirects with OpenID and we don't know > exactly how complex a change to the OpenID libraries would be. > > > > And it's not like you have an RP > > implementation that *almost* works except not quite because the > > libhttp-follow-redirects- > > > and-return-the-content-and-the-final-URL-unless-the-redirect-was-a-303-in-which-case- > > return-the-intermediate-url function in your web framework is returning > > something incompatible with OpenID. (Or, if it is, I really want to > > hear about what HTTP client implementation you're using.) > > > Well, many HTTP clients provide clear hooks into redirect chain. > > > > I know that *you* think the semantics are clear, but the fact that > > knowledgeable people have been haggling over it for weeks on the list > > suggests that it may not be. > > > Well, from my perspective it seems like eventually most people on the list > agreed that it was an issue as outlined by my use case. In any case, the > simplest things are often discussed at great length, if for not other reason > than the colour of the bikeshed, so this is a non sequitur. > > > > So, IMHO, the best way to make this problem go away is to just say that > > 303s are an invalid way of telling an RP where discovery information is. > > > As I mentioned above, instead of altering how all the existing 303d OpenIDs > (again, perhaps I am the only one using OpenID like this) are handled, you > would > break them all, permanently. > > > > RPs will continue to work the way they do now, for backwards-compatibility > > purposes > > > How are you so sure? Perhaps they will just stop working one day. > > > > and anyone publishing OpenID identifiers in the future will be able to > find a > > clear statement about it in the spec. > > > This makes no sense. The current specification clearly tells me why my 303 > redirect doesn't work, but that offers no comfort for me in the same way as > future explanation explaining why my 303 no longer works will also offer no > comfort. Perhaps it'd help if you described exactly what your use case is. 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. James. _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
