RE: Cacheing "CGI requests"

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 http://www.w3.org/ 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 [mailto:kjell@cmr.no]
> Sent: Monday, October 12, 1998 9:13 PM
> To: squid-users@ircache.net
> 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 kjell@cmr.no
>
Received on Mon Oct 12 1998 - 16:46:56 MDT