> - clients may not cache the css response... depending on what form the
> url takes, and what the settings of the client are, and maybe on the
> http headers sent along. If the generated css does not change, then
> caching is clearly a good thing...

Plus Apache is simply faster at serving up this stuff. I let the web
server deal directly with images (mostly) and CSS.

> Unrelated question, about StaticPage... when running behind apache,
> what is the overheard of passing static files thru qx+StaticPage as
> opposed to using something like /static derved directly by apache? Is
> the only advantage to using StaticPage to be webserver independent?

Could be an order of magnitude faster using Apache directly. 931 requests
per second in a simple test (ab -c 4 -n 400 http://path.to.static.css ),
to access a 2KB CSS file; ~ 100 requests per second to request a 2KB
static file from one of my site applications. Granted I've got a bunch of
processing overhead in my static file subclass - but its a very convenient
approach to put wrappers around static file components, wrappers that have
some dynamism to them...