Script Resource and HTTP 304

Problem – HTTP 304 (‘Not Modified’) status response every time a page(rendered html) has reference to ScriptResource.axd or WebResource.axd.
To replicate the behaviour, do a browser refresh on any web page that has ScriptManager. Use Fiddler or similar software to view the 304-response.

Context – This reference is added by Ajax tool kit. ScriptManager adds .axd references in the rendered html to get the javascript support for AJAX.

User Impact –The user would neither getting any server-side error, nor any AJAX errors. But, some server traffic-monitoring software like the Tealeaf show these HTTP 304's as errors in their statistics.

Probable Causes –
When the actual page gets rendered with #pragma set to ‘no-cache’ and such page is refreshed, the broswer tries to load again from server.

When we verify the request/response headers –
Request headers for both page and .axd files would have cache-control set to ‘no-cache’
While the response headers  differ as,
page would still have ‘no-cache’, the .axd file response (with 304 status) would have ‘public’, which means the file can be cached.

Hence, the browser would try to verify the .axd file version with cached version and hence, the HTTP 304 – ‘Not Modified’ status.
304 basically says, the resource is not modified from its last cached copy.


Though this is more a feature than an error, you can try to work it around not to let 304 status response. For instance,
Force-get the .axd files as if they are not cached
To do this,

• Extend the ScriptResourceHandler (that implements IHttpHandler) and Override the ProcessRequest method.
• Set the Expires property to a past date (which would effectively set the cache-control to ‘no-cache’).
• Explicitly setting cache-control to ‘no-cache’ is also necessary to handle the behaviour on all browsers.

Doing this can have a slight impact on performance, but it should be consistent.


MY CONCLUSION ON THIS -
From my knowledge and analysis on HTTP 304’s, this is a feature of HTTP rather than a bug. That’s the correct message the server is sending in accordance with HTTP protocol, and it is not an error/warning message, but just a status message.


304 basically says, the resource is not modified from its last cached copy and the browser can load it from its local cache. This way, it avoids the resource being unnecessarily transferred between client and server, thereby, enhancing the performance of the application.


Some IIS traffic-monitoring software, like the Tea leaf can misread it as an error, while it is actually a feature. They will have to be configured accordingly.


PS: Please comment if this served your purpose by any chance. Happy coding :)