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 t
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 U
tions
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 usin
www.majordojo.com/2007/02/what-openid-needs.php
I share many of same opinions. If OpenID is going to be practically usable
by the average person, we cannot require the person to remember some very
complex identifier. When I signed up for Yahoo's OpenID service, it
presented me with a hideous
that the query
> can be encoded in the fragment if a fragment is present in the return_to URL.
> If the spec were to say it is
> valid, then there is no incorrect behavior (as no other spec is otherwise
> violated).
Yup, great point. We can just say that it is valid (as Google and Ya
mate question here is whether it is acceptable for the
> OpenID spec to define that the query
> > can be encoded in the fragment if a fragment is present in the return_to
> URL. If the spec were to say it is
> > valid, then there is no incorrect behavior (as no other spec is otherwis
mate question here is whether it is acceptable for the
> OpenID spec to define that the query
> > can be encoded in the fragment if a fragment is present in the return_to
> URL. If the spec were to say it is
> > valid, then there is no incorrect behavior (as no other spec is otherwis
