Thanks for all of the suggestions. Looking for REDIRECT_* environment
variables seems like it will work for me.
2010/3/19 Torsten Förtsch :
> On Thursday 18 March 2010 21:59:26 E R wrote:
>> To serve the file the CGI script issues an internal redirect to a url
>> which points to the cached results
On Thursday 18 March 2010 21:59:26 E R wrote:
> To serve the file the CGI script issues an internal redirect to a url
> which points to the cached results.
>
> My question is: can the url which points to the cached results be
> protected so that it cannot be directly accessed by external clients?
Both very good points! I stand corrected.
Michael Peters wrote:
On 03/18/2010 06:05 PM, Michael A. Capone wrote:
This would be the most secure way.
Saying it's the *most* secure way is a little stretch. It's *another*
secure way. Also, keeping a large Perl/CGI process alive just to serve
a
On 03/18/2010 06:05 PM, Michael A. Capone wrote:
This would be the most secure way.
Saying it's the *most* secure way is a little stretch. It's *another*
secure way. Also, keeping a large Perl/CGI process alive just to serve a
static file is a waste. In fact, if you can think of a mod_rewrite
Rather than doing the URL redirect, why not just keep the cached results
in a private directory, and let the CGI open them and serve them up
directly? This would be the most secure way.
So, you could do something like this:
#
On 03/18/2010 04:59 PM, E R wrote:
My question is: can the url which points to the cached results be
protected so that it cannot be directly accessed by external clients?
You should be able to do something like this for that block
(so you might have to put that URL inside of a separate
blo
Hi all,
This is not exactly a mod_perl question - in fact I hope there is a
solution which does not use mod_perl.
I have a CGI script which generates a lot of output. Because it takes
a lot of time to the output, the results are cached in case the same
request is made again.
To serve the file th
