Output caching is a powerful ASP.NET feature that allows you to store dynamically generated page responses. In this way, subsequent requests for the same page are satisfied without executing the page; the cached output is simply returned. Output caching can take place at two levels—entire pages or portions of the page. In the latter case, the portion of the page to be cached is an embedded user control. Page caching is smart enough to let you save distinct output based on the requesting URL, query string or form POST parameters, and even custom strings.
The @OutputCache directive
You can use the @OutputCache directive to declaratively control the caching capabilities of the resource. The directive accepts a handful of attributes, a couple of which are mandatory—Duration and VaryByParam. The Duration attribute indicates, in seconds, how long the system should cache the page output. The VaryByParam attribute allows you to vary the cached output depending on GET query string or form POST parameters. The following declaration will cache the page for one minute, irrespective of any GET or POST parameters:
<%@ OutputCache Duration=”60″ VaryByParam=”None” %>
The @OutputCache supports six attributes that indicate the location of the cache, its duration, and the arguments to use to vary page caching. Table A lists the supported attributes.
As mentioned, the VaryByParam attribute is mandatory. If you omit it, a runtime exception is always thrown. An empty string is not an acceptable value for the VaryByParam attribute, so if you don’t need to vary by parameters, set the attribute to None.
Configuring the output cache
When the output caching service is active on a page—that is, when the @OutputCache directive has been specified—the Duration attribute indicates the seconds that the ASP.NET system will cache an HTML-compiled version of the page. Subsequent requests for the same page, or for an existing parameterized version of the page, will be serviced by passing the page handler.
Setting the Duration attribute on a page sets an expiration policy for the HTTP response generated by the ASP.NET runtime. The output is cached for exactly the specified number of seconds. In the meantime, all the incoming requests that hit one of the cached pages are serviced by the output cache module rather than by the ASP.NET pipeline.
The output cache can be located in various places, either on the client that originated the request or on the server. It can also be located on an intermediate proxy server. Table B summarizes the possible locations.
Most browsers and intermediate proxies exploit any expiration information that the Web server embeds in the HTML page being generated. Two HTTP 1.1 headers relate to page caching: Expires and Cache-Control.
The Expires HTTP header is used to specify the time when the client should update a particular page on the server. Until then, any new request that the browser receives for the resource is served using the local, client-side cache, and no roundtrip to the server is ever made.
When specified and not set to No-Cache, the HTTP 1.1 Cache-Control typically takes values such as public or private. A public value means that both the browser and the proxy servers can cache the page. A private value prevents proxy servers from caching the page; only the browser will cache the page. The Cache-Control is part of the HTTP 1.1 specification and is supported only by Internet Explorer 5.5 and higher.
If you look at the HTTP headers generated by ASP.NET when output caching is enabled, you’ll notice that sometimes the Pragma header is used; in particular, when the location is set to Server. In this case, the header is assigned a value of No-Cache, meaning that client-side caching is totally disabled on both the browser’s and the proxy’s side. As a result, any access to the page is resolved through a connection. To be precise, the Pragma header set to No-Cache disables caching only over HTTPS channels. If used over nonsecure channels, the page is actually cached but marked as expired.