httpd-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <>
Subject Re: flood: responsescript patch
Date Tue, 12 Aug 2003 00:58:22 GMT

On Monday, August 11, 2003, at 04:26  PM, Justin Erenkrantz wrote:

> --On Sunday, August 10, 2003 23:24:04 +0200 Jacek Prucia 
> <> wrote:
>> This probably belongs in contrib/patches. It is a quick'n'dirty hack I
>> did few days ago, to simulate applet making network connection.
>> Basically it allows for something like this:
>> <url responsescript="/path/to/"></url>
> I wouldn't see an issue just placing this in the main code rather than 
> as a separate patch.  Just place in the documentation that the use of 
> this attribute may distort the timings.

I agree. +1

This patch looks cool, but there's one little problem. If the response 
body is bigger
than the internal IO buffers on your system, you'll block trying to 
write. If the
script fails to read or fails to read enough of the body, then flood 
and the script will
deadlock. A better (but more complicated) way to do this is with a 
pollset, so flood
can poll on reading and writing from the script's stdout and stdin.

> Hmm.  If we did this *after* the close is done, would we still have a 
> problem with the timing?  I don't think we would, but I could be 
> wrong. (Perhaps we're freeing the response buffer at that time.  I 
> forget.)

There may be cases where we'd want to keep the connection to the server
open while the script processes, but I can't think of any. We could 
have it default
to run the script after close, and then later if someone comes up with 
a use
case, we could add a flag or something.


View raw message