Leon Rosenberg wrote:
I think the quick and dirty solution would be to send a redirect to
the same url with a dummy param after you copied the file from the
filter and abort execution. The second request should get the file
then.
Yea, I've considered that. The only issue at the moment is sometimes it
take TWO clicks through for the file to show up, so there's no guarantee
(to me at least) that the redirect will actually work.
For the future development I would consider streaming the content of
the file through a servlet instead of copying it. Depending on the
number and size of the resources you could cache everything and be
faster.
It would just be nice if Tomcat exposed their logic for this. My point
being that Tomcat ALREADY does this kind of streaming, the OS does the
caching for me, so such a fundamental process shouldn't have to be
rewritten. Also, at least with Tomcat 4, for some bizarre reason with
PDFs, if we streamed the data, we'd have strange behaviors, but if
Tomcat delivered the file, they would work fine. We duplicated the
headers, checked everything with a proxy, and couldn't tell the
difference, but apparently Acrobat could. So, we write PDFs to disk and
have Tomcat deal with it.
I wonder if it would work with a Forward. Servlet takes the request,
creates the file if necessary, then Forwards to the new file. Use the
servlet as a crude renaming device.
Regards,
Will Hartung
([EMAIL PROTECTED])
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
