How to lose your Authorization head(er) with a bad URL

I've been researching an issue for a customer who was convinced that their Authorization header was being stripped out of their request to their REST service on a specific version of Windows Server.  When a claim like this is made by a customer, the first thing I need to do is validate it.  In this case, it didn't matter what version of Windows was being used, the header was being stripped and at first it really wasn't clear why.  After some investigation using Fiddler 2, I saw that the REST service was returning a 307 response.  A 307 response is sent back to the client any time there is a redirect to a different URL with the location the client should follow listed in the location header.  If you are using a HttpWebRequest to call your service, this redirect happens automatically by default.  Unfortunately, when the redirect is completed, the Authorization header is removed from the new request.  This is so HttpWebRequest can try to reauthenticate to the redirected location.  Unfortunately, if you mistype the URL to your REST service by perhaps not specifying a fully qualified domain name or by forgetting a trailing slash, you will get this redirect to the same server with the corrected URL. 

Typically this is not a problem if you follow best practices and have your authentication taking place outside of your WCF REST service.  However if you are passing custom information in your request on the Authorization header, it will appear to you that gremlins stole your header!

A way to get around this would be to set the AllowAutoRedirect property on the HttpWebRequest to false.  From the MSDN documentation:

The Authorization header is cleared on auto-redirects and HttpWebRequest automatically tries to re-authenticate to the redirected location. In practice, this means that an application can't put custom authentication information into the Authorization header if it is possible to encounter redirection. Instead, the application must implement and register a custom authentication module. The System.Net..::.AuthenticationManager and related class are used to implement a custom authentication module.

So if your custom Authentication information suddenly isn't being passed into your service properly, you probably have a bad, old or malformed URL.  Check your return code from your request and if it's a 307, look in the location header of the response and issue your request again with the corrected URL.

Comments

• Anonymous
  November 04, 2015
  Thank you, thank you!! The missing-in-action Authorization header has been plaguing me for days.  Adding a trailing slash fixed my app.

• Anonymous
  February 03, 2016
  Hi Paul, Thank you for your article. Is there a workaround if I want to forward Authorization to Redirected URL? May be an IIS Setting or IIS Configuration in URL Rewrite

• Anonymous
  February 03, 2016
  Harsh, the MSDN documentation has been updated with guidance for your case: ...Instead, the application must implement and register a custom authentication module. The System.Net.AuthenticationManager and related class are used to implement a custom authentication module. The AuthenticationManager.Register method registers a custom authentication module. This is what you need to do.