Re: DO NOT REPLY [Bug 4361] - SsiServlet potentially leaks files

[Paul Speed <ps...@progeeks.com>]

On a vaguely related note...

For the curious reader, after looking into this code at some length
it seems clear why the set command was not added.  All SSI requests
share the same environment, which not only makes a set command 
impossible but also means that multiple SSI requests (or even nested
SSI requests) trample all over each other.  A simple shtml file that
includes two other shtml files illustrates this quite nicely.

Since I'm between assignments at the moment, I'm working on a patch
here locally.  It's pretty significant, though, so it may take me a 
few days.  It will include the set command though since that's what
I'm going to use to test it. :)

If noone else beats me to it, I'll post it when I'm done.
-Paul Speed

bugzilla@apache.org wrote:
> 
> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4361>.
> ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
> INSERTED IN THE BUG DATABASE.
> 
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4361
> 
> SsiServlet potentially leaks files
> 
> ------- Additional Comments From pspeed@progeeks.com  2001-10-23 12:39 -------
> I can't recreate the error here but I did happen to notice something as I was
> browsing through the code.  Each SsiInvokerServlet request causes it to open the
> requested file as a Resource.  The InputStream that is obtained from this
> Resource is never closed.  I tried to poke around in the Resource classes to see
> if some magic was closing the stream but couldn't find anything.
> 
> I can attach a patch if needed, but the change is pretty simple.  Just a
> try/finally with a close().