I have a two server system... one hosting the app and the other hosting the authentication/authorization. When the app detects the user isn't logged in yet, it redirects to the auth server and passes, as a parameter, the URL originally requested by the user so that after authentication, the user will be redirected back to the app server to the exact URL originally requested.
However, if that original URL contains a #, the whole routine is hosed. It appears that the browsers are decoding the url encoded parameter and, as a consequence, dropping anything after the # to the floor. I've tried this on Chrome, Safari and Firefox.
Example:
Original URL:
https://xxx.com/#/main/by-users?param1=53¶m2=13¶m3=39
Redirect URL:
https://yyy.com/signin/?returnURL=https%3A%2F%2Fxxx.com%3A80%2F%23%2Fmain%2Fby-users%3Fparam1%3D53%26param2%3D13%26param3%3D39
Browser shows:
https://yyy.com/signin/?returnURL=https%3A%2F%2Fxxx.com%2F#/main/by-users?param1=53¶m2=13¶m3=39
As you can see, everything including and after the # is decoded. Thus the server never gets the full 'returnURL' parameter value. It basically just gets
https://xxx.com/
This must be part of some spec someplace, though it seems insane that an encoded # should be decoded and dealt with as if it were never encoded in the first place. But how does one get around this?
Thanks.
Not sure if it is the best solution or even if you can control this, but it may work if you do double-encoding: for example, instead of "%23", make it use "%2523".
The unwanted decoding should then convert "%2523" to "%23", leaving the desired result in the redirect URL that the browser shows.
You need to URI-escape the "#" character.
来源：https://stackoverflow.com/questions/18882857/hashtags-in-url-encoded-parameters-decoded-on-redirect