Wandering Thoughts archives

2007-03-22

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.

web/ConditionalGETIrony written at 23:47:13; Add Comment

Making user home directories on a stock Solaris machine

I was charmed to recently discover that Solaris 10 still hasn't fixed that 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 issue.

  1. useradd -c Whatever <login>
  2. mkdir /export/home/<login>
  3. chown <login> /export/home/<login>

    (This may or may not get the group ownership right. It's hard to care.)

  4. set the login's initial password with: passwd <login>
  5. now, edit /etc/auto_home to add a line saying:
    <login> localhost:/export/home/&

    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 dotfiles from /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 $PATH.)

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 directory is /export/home/<login> with 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 catman -w.)

solaris/MakingUserHomedirs written at 18:35:02; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.