An irony of conditional GET for dynamic websites
Ironically, dynamic websites are the least served by HTTP conditional GET, 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.)
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.
|
|