RE: Cacheing "CGI requests"

From: Nottingham, Mark (Australia) <>
Date: Tue, 13 Oct 1998 09:45:34 +1000

It can be done, but there are catches:

1. the CGI must produce a 'Last-Modified' header
2. the CGI must determine when an If-Modified-Since request is made, and
respond appropriately (304 Not Modified)
3. the proxy must be configured to cache the response (i.e., if it's URL
is in cgi-bin or has a query (?), many caches are configured to not
store it).

There are many ways to do this; I'm in the middle of designing a system
to distribute authenticated, CGI-based information worldwide through a
series of HTTP/1.1 compliant acellerators, hopefully with a Cisco
Distributed Director on the front end. For my next trick...

See the HTTP/1.1 drafts on for more details. I'm in
the process of writing a paper on how to do this, stay tuned.

POST can indeed not be cached. The implications: use GET. If you're
doing large post, chances are it isn't cacheable anyway.

> -----Original Message-----
> From: Kjell Roeang []
> Sent: Monday, October 12, 1998 9:13 PM
> To:
> Subject: Cacheing "CGI requests"
> Hi
> I have an application where I process and distribute some
> data using HTTP.
> The application that "process" the data is some kind of "CGI"
> program that
> takes some input file(s) and paramters an generate an output
> file. The last
> modified date of this processed file is then the last
> modified date of the
> input file. I also want to "resuse" the result over several
> requests and
> clients. My questions are then:
> Can/should I use Squied to store and distribute the results?
> Is there any "optimal" configuration setup to do this?
> I have read that POST requests can not be cached. Is that true and
> want implications does that have?
> Thanks
> Kjell
> Kjell Rĝang
> Tlf. 22 49 19 23
> email
Received on Mon Oct 12 1998 - 16:46:56 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:42:27 MST