mod_include/5867: Cancelation of SSI-request doesn't stop server job

[Frank Schulze <fs...@mrsfs1.mw.tu-dresden.de>]

>Number:         5867
>Category:       mod_include
>Synopsis:       Cancelation of SSI-request doesn't stop server job
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    apache
>State:          open
>Class:          sw-bug
>Submitter-Id:   apache
>Arrival-Date:   Mon Mar 13 02:40:00 PST 2000
>Closed-Date:
>Last-Modified:
>Originator:     fschulze@mrsfs1.mw.tu-dresden.de
>Release:        1.3.0
>Organization:
apache
>Environment:

uname -a
SunOS rks6 5.5.1 Generic_103640-32 sun4u sparc SUNW,Ultra-2

>Description:

There's a *.shtml-page that includes the <!--#exec...--> ...ution of
some shell script.  It takes the script a while to do any 
sophisticated things.  The user (client) is impatient an cancels 
the request (e.g. moves towards another webpage):

To me it seems that the execution of the shell script on the server
is completed - and not terminated - although its output will be 
rejected anyway.

>How-To-Repeat:
Easily.  8->
>Fix:

Is it possible to catch any signal about the cancellation of the 
request by the client, and kill the job running on the server?

Is it possible to define for SSI (and for CGI-scripts too) an
upper limit of CPU-time the may consume ... and to kill them
automaticly, if they exceed that limit?

>Release-Note:
>Audit-Trail:
>Unformatted:
 [In order for any reply to be added to the PR database, you need]
 [to include <ap...@Apache.Org> in the Cc line and make sure the]
 [subject line starts with the report component and number, with ]
 [or without any 'Re:' prefixes (such as "general/1098:" or      ]
 ["Re: general/1098:").  If the subject doesn't match this       ]
 [pattern, your message will be misfiled and ignored.  The       ]
 ["apbugs" address is not added to the Cc line of messages from  ]
 [the database automatically because of the potential for mail   ]
 [loops.  If you do not include this Cc, your reply may be ig-   ]
 [nored unless you are responding to an explicit request from a  ]
 [developer.  Reply only with text; DO NOT SEND ATTACHMENTS!     ]