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
(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
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.
Making user home directories on a stock Solaris machine
I was charmed to recently discover that Solaris 10 still hasn't fixed
useradd issue I saw with Solaris 9.
For my future reference, since I am likely to wind up doing this a lot,
here is how I add users on Solaris 10; this may or may not be the
officially approved way to work around the
useradd -c Whatever <login>
chown <login> /export/home/<login>
(This may or may not get the group ownership right. It's hard to care.)
- set the login's initial password with:
- now, edit
/etc/auto_hometo add a line saying:
Usefully, you don't need to restart any daemons to get this to take effect.
Theoretically you can now log in to the new account and copy the default
/etc/skel to your home directory, but as far as I can
see they don't actually have anything useful so you're not actually
missing anything. (Certainly they don't set a useful Solaris
If you want to skip all of this at the cost of some ugliness in home
directory location, just manually specify that the new user's home
useradd -d. I may wind
up doing this for expendable VMWare installs of Solaris, since it's
faster and less annoying.
(Also for my future reference, the index that
man -k needs on Solaris
10 is created with