2009/10/21 Chris Butler <crispyg...@googlemail.com>:
>
> Hi Graham,
>
> It turns out the new module (with the patch from that other thread)
> was not effective in fixing the problem, it turned up again this
> morning.
>
> On Oct 15, 11:31 pm, Graham Dumpleton <graham.dumple...@gmail.com>
> wrote:
>> So, not sure forcing a dependency on specific version of Apache is
>> necessarily a good idea if you are doing this as part of official
>> Debian repository packages.
>
> The dependency I added was just part of a locally-built package, just
> to make sure we recompile mod_wsgi when the apache major version
> changes to be on the safe side. Still, I'll probably remove it next
> time, if that's not actually where the problem lies.
>
>> What I would be more concerned about though is if the version of the
>> APR library changed between the two Apache versions. If it did,
>> especially if it went from 0.9.X to 1.X of APR, then I could see
>> issues.
>
> It looks like the apr package has been rebuilt since the apache
> packages were built, in order to fix the security flaw in
> CVE-2009-2412 (overflow in pool allocations). However, the version of
> apr stayed the same (1.2.12), so it shouldn't cause problems.
The only remaining section of code where timeout isn't being applied
to socket is for:
}
while (!seen_eos);
apr_file_pipe_timeout_set(tmpsock, timeout);
/*
* Close socket for writing so that daemon detects end of
* request content.
*/
shutdown(daemon->fd, 1);
/* Scan the CGI script like headers from daemon. */
if ((status = ap_scan_script_header_err_brigade(r, bbin, NULL)))
return HTTP_INTERNAL_SERVER_ERROR;
/*
* Look for special case of status being 0 and
* translate it into a 500 error so that error
* document processing will occur for those cases
* where WSGI application wouldn't have supplied
* their own error document.
*/
if (r->status == 0)
return HTTP_INTERNAL_SERVER_ERROR;
/* Transfer any response content. */
ap_pass_brigade(r->output_filters, bbin);
That is, after the call to apr_file_pipe_timeout_set().
No timeout was applied on the basis that WSGI application would always
reply and if it doesn't it is a bug in code. The traces on daemon side
is showing that no WSGI application code is running though, so it must
have returned. Thus doesn't make a great deal of sense.
First thing to try is to comment out the call of:
apr_file_pipe_timeout_set(tmpsock, timeout);
By commenting that out, the value of Apache Timeout directive will
apply to getting response from WSGI application.
Thus, if default for Apache of 300 seconds for Timeout is used, then a
WSGI application must never go more than 300 seconds between returning
data blocks from response.
Normally this would be more than enough. If however you have reduced
Timeout to a lessor value, then you would for time being need to
ensure that Timeout directive value at least greater than longest time
any valid response takes to generate response headers or next data
block.
Although I wasn't sure that having a timeout on the response was
necessarily a good idea, looks like I should at least provide a
'socket-timeout'. This would be off by default, but could be set such
that that connection between Apache server child process and daemon
process would be dropped if length of time between any reads of
response data exceeded that amount.
Wouldn't call this 'request-timeout' as that has other connotations
from prior use in other systems and relates to total amount of time
for request to complete, regardless of whether it is still streaming
data.
Is possible I may need to have separate 'receive-header-timeout' and
'receive-content-timeout' to distinguish between gaps between waiting
for parts of response header versus parts of response content.
Will have to think about it. In effect though might have:
}
while (!seen_eos);
/* apr_file_pipe_timeout_set(tmpsock, timeout); */
/* XXX Timeout for individual reads for response header. */
apr_file_pipe_timeout_set(tmpsock, receive_header_timeout);
/* XXX */
/*
* Close socket for writing so that daemon detects end of
* request content.
*/
shutdown(daemon->fd, 1);
/* Scan the CGI script like headers from daemon. */
if ((status = ap_scan_script_header_err_brigade(r, bbin, NULL)))
return HTTP_INTERNAL_SERVER_ERROR;
/*
* Look for special case of status being 0 and
* translate it into a 500 error so that error
* document processing will occur for those cases
* where WSGI application wouldn't have supplied
* their own error document.
*/
if (r->status == 0)
return HTTP_INTERNAL_SERVER_ERROR;
/* XXX Timeout for individual reads for response header. */
apr_file_pipe_timeout_set(tmpsock, receive_content_timeout);
/* XXX */
/* Transfer any response content. */
ap_pass_brigade(r->output_filters, bbin);
If this gets troublesome for you, you could as well as comment out the
original apr_file_pipe_timeout_set() call, add those two extra ones
with a hard code value for those two timeouts which seems reasonable.
The first should be greater than length of time taken for WSGI
application to return first non zero block of data for response. It is
the first non zero block of data as WSGI specification says headers
should only be returned when first data block arrives and not actually
when start_response() is called.
The second should be greater than any length of time between yield
blocks of data for response content. The length of this time would
normally only be an issue for applications which stream data using
yield.
Note that both timeout values are in microseconds, not seconds. I
think to generate it if you don't want to deal in microseconds is to
use:
apr_file_pipe_timeout_set(tmpsock, apr_time_from_sec(120.0));
When I get time I will do some testing to validate this idea and look
at some permanent options for enabling timeouts in this part of code.
Changes like would only go into mod_wsgi 3.0 however.
Graham
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"modwsgi" group.
To post to this group, send email to modwsgi@googlegroups.com
To unsubscribe from this group, send email to
modwsgi+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/modwsgi?hl=en
-~----------~----~----~----~------~----~------~--~---
