By default if you don’t send either Cache-Control: max-age, or Expires headers then the user agent has been told that the resource can be cached, but has no way to know whether it has changed on the server. Based on this the user agent will send a conditional GET request to the server to find out if the resource has changed, or if it can be served directly from the local cache (this would look like a 304 response).

A conditional GET will compare versions of a resource based on either the Last-Modified header, or the ETag header. Generally these would have been sent in the original response for a resource. The client will then send either the If-None-Match, or If-Modified-Since headers in the GET request to indicate the resource should ONLY be sent by the server if it has changed.

In this case the dynamic endpoint had not been coded to support conditional GETs, so the images were getting fully downloaded on each request as a 200 response.

The simplest solution is to send Cache-control: max-age in order to allow the user agent to serve the resource directly from the cache without bothering with a conditional GET. Alternatively the endpoint has to check for conditional GET requests and change it’s behaviour to support sending a 304 response if the image hasn’t changed.

The best diagnostic tool to see what is going on is the Net tab in Firebug. This will allow you to check the request and response headers, the response codes, and user agent caching behaviour.

First off, we need to ensure that the routing module doesn’t kick in and attempt to handle the request. This can be achieved by making the following change in global.asax of the MVC app…

routes.IgnoreRoute("{*path}", new { path = @"TestApp\/(.*)" });

You can then create a new virtual directory in IIS under the main site, and convert it into an application to ensure it’s running in a seperate AppPool etc.

The final step is to ensure that web application settings in the parent application don’t cascade and get applied to the child application. This is achieved by wrapping all of the main configuration in a location block, and setting inheritInChildApplications to false like so…

<location path="." inheritInChildApplications="false">
   <system.web>Blah</system.web>
   <system.webServer>Blah</system.webServer>
</location>

The most useful reading on this I could find was this forum post.

I’ve seen lots of respectable developers work on sites without running validators over their work or nosing around in the markup that is generated. People will learn the interface for consuming a particular server control without ever getting near the HTML. You’ll see posts from beginners along the lines of ‘how do I set the src attribute on an image’ – so you learn to set the ImageUrl property on the server control.

I tend to approach development in ASP.Net from the other direction… how can I get the framework to generate this markup that I require in the most effective way? I think there should be minimal difference between how you would author a static site, and the generated markup from a dynamic site. Otherwise you’re compromising the quality of the site to accomodate constraints from the framework that you’re using.

I think ASP.Net is a great framework. However I strongly believe it should be used to build custom controls that serve the specific markup needs you have for a site. Generally if you’re doing things correctly, the actual HTML is purely content and therefore very simple. It’s not actually that much effort to author nice simple custom controls that just serve your requirements and do nothing else.

A simple example is how all of the ‘free’ server controls will always render an id attribute to the client – generally this will be autogenerated and long and bloated. Firstly this can interfere and make it hard to use ID based selectors in CSS, but also (more importantly) you should only render an ID attribute if you need a hook for styling or behaviour. Otherwise you’re simply bloating the stream of data that gets sent to the client, and wasting bandwidth and server resources.

I always tend to build a base custom control class where you can specify whether and ID should be rendered, and also whether the ID should be scoped or not. If set to true, the ClientID property gets written to the output stream (the fully qualified value), otherwise the exact ID that was set on the control. The default for rendering the ID attribute is false. This means that the markup does not get bloated with unnecessary information, and as an author you have complete control over the value that gets rendered (so using ID selectors in CSS is back on the cards).

Javascript is definately back in fashion, with a number of libraries popping up to help out with application development. I think overall this is fine, so long as you have an appreciation of what is actually happening under the scenes. I don’t think a library should dictate the way that you build an application, rather enable you to build it more efficiently.

I’ve started using elements of the Yahoo YUI library which is very impressive. There seem to be a lot of very useful little utility functions available, the kind of thing that you would typically rewrite on each project.

I’m quite curious about how the Microsoft and Yahoo libraries compare. I’ll post some information about this when I’ve had a chance to look in more detail at Atlas.