These are protected files so we have to use authentication and authorization
that is done by mod_perl. And Internet Explorer that use most of our customers
has bug that prevents displaying of PDF (and any other large non-dynamic
non-HTML) files if the URL to that file was result of "Redirect".
Th
Thanks Vivek,
Andrei, use the front end to directly handle any binaries, static files,
etc.
I doubt they are generating of these on the fly.
Vivek Khera wrote:
>
> > "AAV" == Andrei A Voropaev <[EMAIL PROTECTED]> writes:
>
> AAV> In our system we have to pass large PDF files thru mod_pe
> "AAV" == Andrei A Voropaev <[EMAIL PROTECTED]> writes:
AAV> In our system we have to pass large PDF files thru mod_perl to
AAV> proxy and we noticed that it takes the same time as sending it
AAV> directly to customer.
Why do you have to pass the PDF thru mod_perl? Are you generating it
on
> After checking Apache code for mod_proxy looks like it is normal
behaviour.
> File modules/proxy/proxy_util.c function ap_proxy_send_fb. This function
> reads from originating server into buffer and then writes to the customer
from
> this buffer. BUT the socket is closed AFTER all the data is se
On Mon, 17 Sep 2001, Andrei A. Voropaev wrote:
> Hi!
>
> I have one question. According to the Guide there's buffering feature of
> mod_proxy that allows to release heavy mod_perl process from delivering data
> over slow connection to the user.
>
> In our system we have to pass large PDF files th
