Defining how OpenID should behave with fragments in the return_to url

[Martin Atkins]

James Henstridge wrote:
> On Wed, Mar 25, 2009 at 3:33 AM, Luke Shepard <lshepard at facebook.com> wrote:
>> 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.
> 
> How would this interact with OpenID providers that respond via a POST
> request instead of a GET?  This is something they are permitted to do
> according to the spec, and may decide to do so even if the
> authentication request was started with a GET if the response is large
> enough.
> 

This is a good point, but it seems like again it can be worked around by 
making openid_reciever.html accept POST requests.

Unlike the query string, this can't be done completely client side, but 
it ought to be reasonably simple to set up some kind of rewriterule or 
other indirection trick to make POST requests to openid_reciever.html 
actually get served by a non-static endpoint.

To be honest, I'd be surprised if POST requests from OP to RP worked 
interoperably today, but the trick of using the # on the end of the 
return_to URL to signal to a supporting OP "I'm trying to do this 
completely client-side, so don't do a POST request" works here too.