Script Resource and HTTP 304

Here are my findings on HTTP 304’s -

Issue – HTTP 304 every time a page(rendered html) has reference to ScriptResource.axd or WebResource.axd. this reference is added by Ajax tool kit.

Context – ScriptManager adds .axd references in the rendered html as below to get the javascript support for AJAX.

User Impact –
The user is neither being redirected to the error page, nor getting any AJAX/functionality errors. But, some server traffic-monitoring softwares like the tea-leaf show them as errors in their statistics.

Probable Cause –
The actual page is being rendered with #pragma set to ‘no-cache’. So, when the page is refreshed, it is trying to load again from server.

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

Based on the response header’s cache control value, it is trying to verify the .axd file version with cached version and hence, the HTTP 304 – ‘Not Modified’ error. 304 basically says, the resource is not modified from its last cached copy.

Possible Fixes –
Extend the ScriptResourceHandler (that implements IHttpHandler) and Override the ProcessRequest method.

The fix for this should either be – force-get the .axd files as if they are not cached OR use only the cached version of the .axd files.

For the first fix –
Set the Expires property to a past date which would effectively set the cache-control to ‘no-cache’.
Setting cache-control to ‘no-cache’ is also necessary to handle the behaviour on all browsers.

For the second fix – (this may NOT be the recommended one)
Set the status code of the response in the HttpContext to ‘200’ if it is ‘304’.

The first fix can have a slight impact on performance, but consistent.
The second fix is not really consistent(, at least when I verified). Theoritically it should work and it should have no impact on performance.

To replicate the issue, do browser refresh on any that has ScriptManager. Use Fiddler or similar software to view the 304-response.

MY CONCLUSION ON THIS -
From my knowledge and analysis on HTTP 304’s, I’ve found that this is a FEATURE of HTTP rather than a bug. That’s the right 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 softeware, like the Tea leaf can misread it as an error, while it is actually a feature. They will have to be configured accordingly.