title: hashtags (#) in URL encoded parameters decoded on redirect
body: <p>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.</p>
  
  <p>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.</p>
  
  <p>Example:</p>
  
  <p>Original URL:</p>
  
  <pre><code>https://xxx.com/#/main/by-users?param1=53&amp;param2=13&amp;param3=39
  </code></pre>
  
  <p>Redirect URL:</p>
  
  <pre><code>https://yyy.com/signin/?returnURL=https%3A%2F%2Fxxx.com%3A80%2F%23%2Fmain%2Fby-users%3Fparam1%3D53%26param2%3D13%26param3%3D39
  </code></pre>
  
  <p>Browser shows:</p>
  
  <pre><code>https://yyy.com/signin/?returnURL=https%3A%2F%2Fxxx.com%2F#/main/by-users?param1=53&amp;param2=13&amp;param3=39
  </code></pre>
  
  <p>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 </p>
  
  <pre><code>https://xxx.com/
  </code></pre>
  
  <p>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?</p>
  
  <p>Thanks.</p>