Http compression with client-side scripting should be handled with care. The problem can have different symptoms and manifest in different ways, but essentially it has a common root cause and I have already discussed some of the aspects (for example see here and here). This time the customer whom reported the problem was using Forms Authentication in his application so the first time an unauthenticated user browsed it, he was redirected to the login page configured in web.config. So far so good.
Some quick theory
Well, this is not completely true… if you want to have a look at them you can search the IE temporary cache on your client, you’ll likely find quite a few instances of WebResource.axd and ScriptResource.axd, but you’ll not find them on the server to be used by IIS.
At this point I already had some suspects but still no real clue, so let’s go hunting for them.
First thing is to check if you are using HTTP compression: if you do, test if disabling it resolves the problem:
Another possibility is that the application mappings are not configured correctly (try with “aspnet_regiis –i”) or for some reason for the extension .axd the flag “Verify that file exists” flag has been set: if it is, remove it.
Anyway everything looked good on the faulting server so far… So next step is to have a look at the IIS logs.
Using LogParser you can quickly check what IIS returns when it comes to serve WebResource.axd (or the handler you’re looking for):
Result? Every time WebResource.axd is requested, IIS returns a 404 (File not Found):
This time let’s check the Wildcard application mappings… If you have your IIS Manager at hand, give a quick look at the following screenshot:
Otherwise if you are like me and have only the IIS metabase at hand, you can have a look at the ScriptMaps elements you have in there:
Pay attention to the last entry:
What is important here is the “Flags” part: “4” means “The server attempts to access the PATH_INFO portion of the URL, as a file, before starting the scripting engine. If the file can’t be opened, or doesn’t exist, an error is returned to the client”.
Here we are again… Check and clear the flag “Verify that file exists” for your wildcard application mapping. The point is that a wildcard ISAPI extension intercepts all requests and is executed as the first step for every of them; since WebResource.axd does not exist as a file on disk, IIS will not find it, will return a 404 error and will abort the request without passing it to aspnet_isapi.dll for further handling.
This error can con in different forms, sometimes obvious and sometimes not so obvious; but when “dynamic” resources come into the field, spending a couple of minutes to take case of HTTP compression and Application Mappings configuration can save you from complains by your users and hours of troubleshooting and headaches…
Quote of the day:
The folly of mistaking a paradox for a discovery, a metaphor for a proof, a torrent of verbiage for a spring of capital truths, and oneself for an oracle, is inborn in us. – Paul Valery