Joachim Zobel <nc-zobeljo@netcologne.de> writes:
> At 12:15 06.08.2002 -0500, you wrote:
> >As is common on sites, I'm working with a fully-dynamic homepage, with
> >most of the content generated from database queries. It also has a
> >box which shows whether the user is currently logged in to the site
> >(and provides links and form fields to manage that state). I'm low on
> >cpu horsepower (this is a fan site for a fantasy author, hosted out of
> >my basement) and would like NOT to force the homepage to be
> >non-cached. I'm happy to set an arbitrary timeframe for how often it
> >actually checks to see if the database has changed so as to cause
> >different content to appear on the page. However, I haven't
> >implemented anything that deals with getting the login box to update
> >reliably when they log in as one user, goto a page, log in as another,
> >and return to the homepage via a link.
> >
> >The only thing I've been able to think of that might handle this is to
> >generate a strong validator myself, and to handle HEAD requests, and
> >set the caching mode so it checks for each access. That's a *big*
> >step off into deep water for me; anybody know if this is the right
> >general approach for this problem?
> >
> >And if it *is* a useful approach, can somebody point me at the
> >mod_perl constructs for handling head requests? And any pointers,
> >tips, traps, pitfalls, etc.?
>
> This is far too complicated IMHO. The easiest way to get the caching
> behaviour of static pages is to use an SSI "frame" with XBitHack full
> around the pages. Every time you modify the database, you touch the
> frame. This is a bit tricky. The "frame" is not writeable by the
> webserver user (this is good!), so _this_ user can't touch it.
I always prefer simpler solutions. I think it would actually be
simpler to skip the SSI layer and just generate my own last-modified
or equivalent, though.
> The thing you then need to do is to have the URL fully reflect the
> state of the page. If the user logs in, you either add an user=joe to
> the query string or use use URL rewriting to put /user-joe/ in the URL
> path. The second has the advantage that it is preserved if you use
> relative links.
Now, I really should have thought of this. I was pretty careful about
planning the rest of the URL that way, but I somehow didn't think of
including the session identity; too tied up with thinking of that as
being in the session cookie I guess.
If I do this I'll have to be careful that sending a URL doesn't give
away access to your private account on the site, but that's doable;
keep the session in the cookie but duplicate the user ID in the URL.
> The main reason to support caching is however not to save computing
> power or bandwith. Browser caching means end user performance.
Right, my cpu worries were really about the performance seen by the
user; it's just that *I* know the problem is I produce the pages
rather slowly, so far, so *I* think of it as a cpu use problem.
--
David Dyer-Bennet, dd-b@dd-b.net / New TMDA anti-spam in test
John Dyer-Bennet 1915-2002 Memorial Site http://john.dyer-bennet.net
Book log: http://www.dd-b.net/dd-b/Ouroboros/booknotes/
New Dragaera mailing lists, see http://dragaera.info
|