I stumbled across this issue multiple times during my life of web developer (which begun about 10 years ago), it appeared every now and then to complicate things when I was in the middle of a heavy debugging sessions and doing frequent changes to my pages; I was expecting some kind of results but despite the fact that the code was looking good, there were no signs of those changes. Sometimes even adding a new UI element like a button or an image or changing the color of a header had no effect… ? Having a look at the page source within IE demonstrated the browser was somehow right not showing the new image or color because it was not there in the code… where was that source coming from? ?
Well, if it does not come from the web server, then it’s loaded from the IE local cache… so let’s go to Internet Options > General > Delete > Temporary Internet Files, give it another try and guess what? This time it works…! So, not sure why, but for some reason IE was not refreshing its case and was using an outdated version of my pages. Then after a while I forgot about problem.
Last week I got a call from a customer about an applications they are developing, but he was getting a Javascript error on the client-side: “WebForm_PostBackOptions is undefined“. Looking at the page source within IE confirmed that the WebForm_PostBackOptions method was really missing, but we had to discover the reason. As you may know, in ASP.NET 2.0 resource files (such as images, CSS stylesheets, javascript etc…) are served through the WebResource.axd handler, which is for example responsible to serve the client-side javascript code used to post back the page, for validation used by the Validation controls etc… There is a known issue with WebResource.axd where using Http Compression prevents the client-side scripts to render correctly and it’s necessary to exclude the handler from the compression to have it working normally; so we checked if IIS was using Http compression, but it wasn’t.
Next step has been to use Fiddler to trace the http traffic between the web server and the client and everything looked fine, all resources and files (included WebResource.axd) were downloaded correctly… ? Then my past experiences with IE temp cache came back to my mind, and asked the customer to clear the IE cache before trying again: well, as you can guess, that solved the problem! For sore reason IE was downloading the .axd file but kept using the cached (corrupted) one, which did not contain the WebForm_PostBackOptions implementation.
I have to say that every time I encountered this problem, I (or the customer) were developing and debugging on localhost so the machine was somehow playing a double role, not sure it this can be the (very high level) explanation of this weird behavior… anyway remember to clean your local caches and temporary folders if your application starts behaving odd…
Carlo
Quote of the day:
A strong conviction that something must be done is the parent of many bad measures. – Daniel Webster