Defining how OpenID should behave with fragments in the return_to url

Andrew Arnott andrewarnott at gmail.com
Wed Mar 25 02:09:47 UTC 2009


Sorry, but I sorely disagree with option #2.  Perf improvement or no.  As a
perf engineer at Microsoft says, "I can optimize performance down to 0 ms if
I am willing to accept incorrect behavior."
The URI must not contain a hash in the middle of the query string unless
that hash is URI escaped, which of course would defeat the perf gain you're
reaching for.  Therefore I urge OpenID 2.1 to mandate option #1, which I
wouldn't call currently ambiguous since the URI spec is assumed to be
followed and that would mandate it, removing the ambiguity.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - Voltaire


On Tue, Mar 24, 2009 at 4:42 PM, Luke Shepard <lshepard at facebook.com> wrote:

>  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" <breno at 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 <balfanz at 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 <atom at 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 at openid.net
> http://openid.net/mailman/listinfo/specs
>
>
>
>
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>
>
>
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>
>
>
>
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20090324/07860a72/attachment-0002.htm>


More information about the specs mailing list