== An irony of conditional GET for dynamic websites

Ironically, dynamic websites are the least served by [[HTTP conditional
GET AtomReadersAndCondGet]], because by the time they've worked out
whether or not a page's content is the same as what you've already got,
they may well have generated the entire content. As a result, the only
thing conditional GET really gets many dynamic websites is bandwidth
savings, which may go some way to explaining why many dynamic frameworks
don't have very good support for it.

(The same is true for HTTP _HEAD_ requests, generally even more so.
Fortunately they're [[quite rare HTTPInTheWild]].)

I think that what really hurts in this is templating languages. If
you know the content structure going in to page generation, you can
have basic elements with precomputed _ETag_ hash values and so on,
but flexible templates mean that you don't know the content structure
until you evaluate the template to some degree. And the more power the
templating language has, the more evaluation you need to do to know the
content structure.

(The easiest implementation of _ETag_ is to get the ETag value by
hashing the page's more or less full text, which means that you have
to generate most of the page's actual text before you can compute the
value to check against the conditional GET's If-None-Match. Static file
webservers get around this partly by making the _ETag_ value out of
easily gotten things like the inode _stat()_ information.)

It's still useful to generate the HTTP headers necessary for conditional
GET in your dynamic framework, since it preserves your ability to
someday slap in a reverse cache in front of your actual dynamic bits.
And once you're generating the headers, you might as well do actual
conditional GET too; if nothing else you're saving your users some
bandwidth and thus making your site snappier.