in reply to RE: Re: Parsing and Spewing CSS
in thread Parsing and Spewing CSS

This brings up an interesting point. CGI scripts should never be cached by the browser. I believe most (all?) web servers, when serving up any CGI or dynamic (making use of SSI) content, will note a page with, like, an immediate Expires header, or some other mechanism to let the browser know that the page shouldn't be cached.

What if you want data to be cached? Is the best way to accomplish this to emit an Expires header of our own? What about If-Modified-Since-qualified requests? Do we then have to process those, and emit the requisite 304 if no change has been made? In short, is there a module or better mechanism for scripts to participate in the expiration/caching process, or to at least override the server's default behavior of marking CGI-generated content as uncachable?

Replies are listed 'Best First'.
RE: RE: RE: Re: Parsing and Spewing CSS
by Hrunting (Pilgrim) on Nov 16, 2000 at 00:23 UTC
    The best way to accomplish this is to find some documentation somewhere for whatever web browser(s) you are developing for an send the appropriate headers. Each browser has it's own way of specifically denying cachable information. It's a pain in the ass.

    Actually, the way that I'm leaning towards right now is to cache the information locally and send the cached information to the client. This works best under mod_perl, because you don't have to worry about the overhead of starting up a perl processor to handle the return of cached data (like you would normally).

    I've found that IE tends to cache based on what it's user settings are and tends to ignore the Expires: header. And even with the CGI module, you can return whatever headers (status and otherwise) you want.