diTii.com Digital News Hub

Sign up with your email address to be the first to know about latest news and more.

I agree to have my personal information transfered to MailChimp (more information)


Internet Explorer local cache!

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.

Internet Explorer, IE, Cache, Troubleshooting, Knowledgebase, Article, Tips and Tricks

Source:→ MSDN Blog

Share This Story, Choose Your Platform!

Get Latest News

Subscribe to Digital News Hub

Get our daily newsletter about the latest news in the industry.
First Name
Last Name
Email address
Secure and Spam free...