Re: A summary of key points on dynamically generated web pages

On Mon, 22 Nov 1999, Nir Dagan wrote:

> One problem with dynamically generated pages is that one has 
> to configure the server to send the appropriate last-modified 
> response header to allow caching.

This is true - assuming, of course, that we are dealing with a
situation where cacheing of the results is meaningful.

> In addition, the server would like documents to be cached only 
> if it can assure that the cached document that is served to 
> the user is the appropiate variant.

This is also a significant consideration, but only if there is a
relatively small number of variants to be considered.  If the dynamics
are creating different pages every time, with billions of possible
responses (as for example with the results of a search from a search
engine), then these considerations would not seem relevant.  But I
certainly agree with you about the importance of giving thought to
these issues, and making things cacheable when appropriate.

There are useful resources on this topic from Mark Nottingham,
http://www.mnot.net/cache_docs/
and Andrew Daviel, http://vancouver-webpages.com/CacheNow/

> The simplest way to solve this problem is to have 
> prewritten "static" versions on the server, with different URLs, 
> and the server may use redirects (using a response with 302 
> status code) based on content negotiation. 

This is what Andrew Daviel calls the "negotiated redirect", and is 
indeed the only cache-worthy approach that works with pure HTTP/1.0.

> Having each variant with a different URL makes the documents that the users 
> receive non-negotiated documents that can be cached, and using static files 
> makes the last-modified header a trivial matter: 

That's agreed.

However, I've encountered very mixed reactions amongst practitioners
to the idea of promoting its use today, because although definitely
beneficial for pure HTTP/1.0, it actually inhibits some of the
optimisations that are possible in HTTP/1.1 (and some of these
features, e.g the Vary: header, can be present as optional extensions
also in HTTP/1.0, so one does not necessarily have to wait for
comprehensive deployment of full HTTP/1.1 capability before starting
to apply them).

I didn't disagree with the rest of what you said; and it's true that
some of the technical issues raised here have not been specific to web
accessibility considerations - but I thought it might be useful to at
least mention the issues here, now that the "negotiated redirect" has
come up in the discussion.

all the best

Received on Tuesday, 23 November 1999 11:16:21 UTC