Subscribe: Frank Hecker - Blosxom
http://hecker.org/blosxom/index.rss
Added By: Feedage Forager Feedage Grade B rated
Language: English
Tags:
date time  date  etag  header  lastmodified plugin  modified header  modified  page  plugin  time  validation  weak validation  weak 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Frank Hecker - Blosxom

Frank Hecker - Blosxom



Notes on the Blosxom blogging system and my contributions to it



Updated: 2006-07-23T16:37:00Z

 
























The lastmodified2 plugin

2005-01-09T13:43:00Z

In a previous post I discussed the general problem of validating and caching dynamic content. In order to implement the strategy outlined in that post I decided to create a new version of the lastmodified plugin originally created by Bob Schumaker. The lastmodified plugin was a good base to build on; however it didn't do exactly what I wanted to do, and hence I couldn't resist trying to improve on it. The following material documents the lastmodified2 plugin that I created, including my notes on how I implemented page validation according to my interpretation of the HTTP 1.1 specification. The strategy revisited As you may recall, in my previous post I outlined an overall strategy for how to support validating and caching dynamic content. Here's a recap of that strategy, with additional detail added on the subject of validation: When sending responses to requests, add a Content-length header to identify the total number of bytes in the response. When sending responses to requests, add an ETag header to identify the "version number" (entity tag) for this particular version of the page, and/or a Last-Modified header to identify the date/time the page was last modified. These are computed as follows, depending on whether weak or strong validation is used: For weak validation, the Last-modified header should reflect the date/time modified of the most recently-updated "semantically-significant" component of the page. (For example, for Blosxom we consider entries to be semantically significant, but not flavour templates.) The ETag header can then supply a weak etag directly derived from this date/time. For strong validation, the ETag header should change if even a single bit on a page changes; for example, it could be derived from the MD5 or SHA-1 digest of the page. A Last-modified header value could then be determined by consulting a cached copy of the ETag and Last-modified values for the URI; if there is a cache match then the Last-modified value can taken from the cache, otherwise it can be arbitrarily assigned to be a date in the recent past. When sending responses to requests, also add Cache-control and Expires headers to the response to provide a "use by" date/time to clients doing caching. When processing requests, look for the If-none-match andIf-modified-since headers. If one or both are present, return the full page in the response only if necessary: if the version of the page currently available is different than the version requested in the If-none-match header, or if the page has been modified since the date in the If-modified-since header. Implementation overview This section and the next describe in more depth how I implemented the above strategy. First, the plugin is designed to have its behavior easily modifiable using configurable variables, as is done with other Blosxom plugins. In particular, it is possible to specify whether the plugin should do strong or weak validation ($strong boolean variable) and whether it should generate an ETag header, Last-modified header, or both ($generate_etag and $generate_mod boolean variables). By default the plugin is configured to be a "plug-compatible" replacement for the lastmodified plugin, doing weak validation and generating both ETag and Last-modified headers. The basic plan of the lastmodified2 plugin is as follows: start subroutine: Read in the cached information containing the previous ETag and Last-modified values for this URI. filter subroutine: Get the information necessary for weak validation by traversing the list of entries to be displayed on the page and determining the date/time any of the entries was most recently modified. Use this last-modified date/time to create a weak ETag value. skip subroutine: For weak validation interpret any If-none-match or If-modified-since headers and determine whether or not we need to send a full respon[...]