Programming Microsoft ASP.NET 4 - Dino Esposito [394]
The browser uses HTTP headers to determine whether the representation is fresh or stale. The Expires HTTP header indicates the absolute expiration date of the resource. The max-age HTTP header indicates for how long the representation is fresh. If the resource is stale, the browser will ask the origin server to validate the representation. If the server replies that a newer resource exists, a new request is made. Otherwise, the saved representation is served.
These simple rules express the behavior of Web caches—both browser cache and proxy cache. If ASP.NET pages and JavaScript files behave differently, the difference is all in the HTTP headers that accompany them.
Typical Behavior of an ASP.NET Page
An ASP.NET page is a dynamic resource, meaning that its content might be different even when the requesting URL is the same. This structural attribute makes an ASP.NET page a noncacheable resource. An image that represents a company’s logo or a script file, on the other hand, is a much more static type of resource and is inherently more cacheable.
By default, an ASP.NET page is cacheable by browsers but not by proxy servers. However, an ASP.NET page has no expiration set and subsequently is always stale. For this reason, any request you make for an ASPX resource will always result in an immediate refetch from the server as if the page was never cached. Figure 18-6 shows this.
Figure 18-6. ASPX pages are always fetched from the server.
The screen shot shows that default.aspx is requested as usual, whereas cascading style sheets (CSS), images, and scripts are checked and served from the local cache because they are not modified.
The default behavior of the ASP.NET page results from a similar payload and especially from the Cache-Control header.
Cache-Control private
Content-Type text/html; charset=utf-8
Server Microsoft-IIS/7.5
X-AspNet-Version 4.0.30319
X-Powered-By ASP.NET
Date Thu, 02 Dec 2010 17:56:06 GMT
Content-Length 12315
You can change at will the caching settings for any ASPX page. One of the tools you can use for doing so is the @OutputCache directive that I’ll cover in just a moment.
Typical Behavior of Static Resources
Typically, static resources are served with a relatively long lifetime, with the goal of staying in the cache as much as possible. Obviously, developers as well as Web masters are ultimately responsible for deciding about the maximum age allowed for a given set of resources. For static resources, you can set HTTP headers from the Web server (for example, IIS) management console. (See Figure 18-7.)
Figure 18-7. Typical response headers for a static resource.
The figure shows the response headers of a JPEG file, which is given about a month of life in the browser cache. Modern Web servers add an ETag header, which represents a hash calculated on the content of the resource. They also include the Last-Modified header with the timestamp of the server resource. When the resource gets stale and both the ETag header and timestamp match, you can be really sure that the resource is still the same.
Making ASP.NET Pages Cacheable
As mentioned, by default ASP.NET pages are not served from any cache, neither the browser cache nor some proxy cache in the middle. This behavior is inspired by the fact that an ASP.NET page, in general, is a dynamic resource whose content might change frequently. There are many situations, however, where it is acceptable for a page response to be a little stale if this brings significant performance advantages. Want an example?
Think of an e-commerce application and its set of pages for the products catalog. These pages are relatively expensive to create because they could require one or more database calls and likely some form of data join. All things considered, a page like this could easily cost you a few million CPU cycles. Why should you regenerate this same page a hundred times per second? Product pages tend to remain the same for weeks and are rarely updated more than