http status codes - Eradicating 401 "Unauthorised" responses followed by 200 "Ok" responses

Question

I’ve got a situation with a large internal corporate web based application running ASP.NET 3.5 on IIS6 generating 401 “Unauthorised” responses followed by 200 “Ok” responses (as profiled by Fiddler). I’m aware of why this happening (integrated auth forcing the browser to resend credentials) but I’m looking for some thoughts on how to minimise or eradicate the situation. The application in question is running in the WAN with some users experiencing latency of up to 250ms so forcing a subsequent request can have a noticeable impact on page load time, particularly when there are a number of cascading drop down lists on the pages making.

The users of the application are internal within a managed desktop environment so mechanisms to force the browser to send credentials on the first request (is this even possible?) could be possible from a deployment perspective. This would work for pages requiring the user’s identity but for resources not requiring authentication (WebResource.axd, ScriptResource.axd and some custom web services), allowing anonymous auth would be possible. I’ve looked at defining this on a per location basis in the web.config but the results were mixed (still a number of 401 responses).

I’d appreciate any guidance on a “best practice” for dealing with this situation. There are a lot of resources out there identifying the problem but none that I’ve found providing a feasible solution.

Thanks!

Edit: Resources not requiring authentication (i.e. web services used for cascading drop down lists) can be requested anonymously through adding a location entry to the web config but I'm yet to find an answer for authenticated resources.

Answer 1

Unfortunately this is an artifact of the HTTP NTLM authentication scheme.

In short, the browser (Internet Explorer or otherwise) doesn't know that it needs to authenticate at all until it gets bounced with a 401 response containing a WWW-Authenticate response header.

In the case of WWW-Authenticate: NTLM -- annoyingly enough -- it requires two 401 responses on a single persistent connection to complete, and this process must be repeated once the HTTP persistent connection is closed. So even if you were able to get the browser to initiate a request blindly attempting NTLM, at least one 401 response cannot be removed from the transaction.

I think your best bet would be to maximize the amount of time that persistent connections are left open when idle.