Ha - thanks Breno :) I'm basically saying that the spec is ambiguous, which is proven by the fact that multiple major providers have different interpretations of how to handle this case.
When given a return_to url of http://open.domain.com/openid_receiver.html?query#hash, there are two options for how to return the response: 1. http://open.domain.com/openid_receiver.html?query&openid.ns=....#hash 2. http://open.domain.com/openid_receiver.html?query#hash&openid.ns=.... Section 4.1.2 of the spec says: "When a message is sent to an HTTP server, it MUST be encoded using a form encoding specified in Section 17.13.4 of [HTML401] (W3C, "HTML 4.01 Specification," .)." According to the URI spec, the fragment portion is explicitly undefined, so the "right" way to do this is Option #1, which is to include it in the query string Option #2 is therefore technically wrong. However, it has the nice side effect of allowing this performance optimization. So we should have a way for the RP to specify that they want the return in the fragment, not the query, for performance reasons. I don't think this is something super urgent, but it should be clarified in the next version of the spec. We can probably work it out next time we're in person. On 3/24/09 4:28 PM, "Breno de Medeiros" <br...@google.com> wrote: I must confess that Google's support is also accidental :) Thanks for pointing it out to us, though, we will keep in mind not to ever "fix" it. On Tue, Mar 24, 2009 at 3:12 PM, Dirk Balfanz <balf...@google.com> wrote: Wait - isn't Luke saying that Yahoo! is currently supporting this just fine? What are you "fixing"? Dirk. On Tue, Mar 24, 2009 at 2:16 PM, Allen Tom <a...@yahoo-inc.com> wrote: Hi Luke, I have to confess that I was not aware of technique of passing parameters after the fragment to take advantage of browser caching, until you blogged about it. Since then, we've noticed that developers have been doing this, and in fact, we fixed the same bug on our OAuth service just last week. We will update our OP to support return_to URLs with a fragment. I'll let you know when it's fixed. Thanks Allen Luke Shepard wrote: Hi- I've noticed an ambiguity with the way URLs are handled that exists in the current spec. I'm hoping we can resolve it for OpenID 2.1. When we move the OpenID transaction into a popup window, we need a way for the popup to communicate back with the parent. The way to do this is to set a return_to URL that, when loaded, reads the parameters and communicates with the parent window somehow. Here's a description of a technique: http://www.sociallipstick.com/2009/02/04/how-to-accept-openid-in-a-popup-without-leaving-the-page/ A simple way to do this is to have a simple receiver. The response will append query parameters: http://open.lukeshepard.com/openid_receiver.php?openid.ns=...... However, there is a small performance problem with this approach. The user will see a blank-looking popup for a moment while the server processes the OpenID arguments. An optimization is to put up a simple, cacheable static HTML file that chucks the OpenID params back to the parent frame. The parent can then provide some visual feedback to the user while it sends the OpenID parameters off for processing. This results in a snappier experience. If the static HTML file has no parameters and sends out long-lived cache headers, then the response won't even trigger a server load, and the whole process can appear faster to the user. In this case, the response would look like this: http://open.lukeshepard.com/openid_receiver.html#openid.ns=...... Note that the hash appears instead of a question-mark. That tells the browser that it doesn't need to load an extra file, and it can save perhaps a quarter or half second of latency for the user on average. Okay, so the point is that different OpenID providers currently interpret the hash differently. I think we should explicitly define a behavior that makes sense and accomodates the above suggestion. Here's how they currently behave. When given a return_to of http://open.lukeshepard.com/openid_receiver.html?query#hash Google: http://open.lukeshepard.com/openid_receiver.html?query#hash?openid.ns=.... Yahoo: http://open.lukeshepard.com/openid_receiver.html?query#hash?openid.ns=.... MySpaceID: http://open.lukeshepard.com/openid_receiver.html?query&openid.ns=....#hash MyOpenID: fails outright - "invalid return_to" By the URL spec, Myspace is technically correct and Google/Yahoo are wrong. But the "correct" way doesn't allow the performance optimization listed above. I'd like to see a way to accommodate the hash url. One crude way to do it would be to have the caller specify that they want the return_to args simply appended instead of integrated into the URL- perhaps an argument like openid.append_return_to_params=true. But that sounds hackish and I'd love to hear feedback on a better way to do this. Also, let me know if this is the wrong list or whatever. thanks, - Luke ________________________________ _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
_______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
