On 7 July 2010 11:43, Graham Dumpleton <graham.dumple...@gmail.com> wrote:
> On 6 July 2010 22:56, Edgar Frank <ef-li...@email.de> wrote:
>> Hi mod_fcgid developers,
>>
>> I'm currently exploring a potential problem with mod_fcgid.
>> Let's assume a setup with mod_security and mod_fcgid
>> (has nothing to do with mod_security itself - it just helps to
>> trigger the problem).
>>
>> Now we have a large POST request which mod_security blocks
>> (by SecRequestBodyLimit) with "413 Request Entity Too Large".
>
> Presumably it might also occur with LimitRequestBody and not even need
> mod_security. Unless that is that this is a problem with mod_security
> itself and how it handles a 413.
>
> So, is the issue with mod_fcgid. If there is an issue here with
> ErrorDocument for a 413 where the handler is a proxy of some form,
> then likely could affect other modules besides mod_fcgid.
>
> I would be investigating where ErrorDocument for 413 is handed off to
> URL implemented by CGI or even mod_proxy to see what happens.
>
> Graham
>
>> The ErrorDocument for 413 is configured to a Location which
>> mod_fcgid serves. (Please don't argue that it's this way - I know
>> the problems and I'm not happy with it, but it's not my decision
>> to do it that way.)
>>
>> HTTPD issues a GET subrequest for the ErrorDocument and
>> mod_fcgid kicks in. But now it starts consuming the request body
>> we just blocked - or if the request body size is larger than
>> FcgidMaxRequestLen, ErrorDocument generation fails.
>>
>> I wonder how to circumvent this. In fcgid_bridge.c:bridge_request
>> I found:
>>
>> if (role == FCGI_RESPONDER) {
>> rc = add_request_body( [...] );
>> }
>>
>> Could one change this to something like the following without
>> causing trouble?
>>
>> if (role == FCGI_RESPONDER && !ap_is_HTTP_ERROR(r->status)) {
>> rc = add_request_body( [...] );
>> }
>>
>> Or maybe something like a HTTP method check? (Is there a
>> reliable way to detect if we're in ErrorDocument generation
>> anyway?)
Addressing this question, r->prev attribute should refer to original
request and so can possibly check r->prev->status.
Also, the following gets set:
apr_table_setn(new->subprocess_env, "REDIRECT_STATUS",
apr_itoa(r->pool, r->status));
before internal redirect. This is more of interest where CGI, or
FASTCGI script actually gets executed as that wouldn't have access to
the original request object.
Graham
> But at this point we have put the Content-Length header
>> already into the stream to the FCGI backend, so one would also
>> have to take action earlier.
>>
>> What do you think in general of handling this? I'd really
>> appreciate an elaborate answer - if you find it fix-worthy,
>> first ideas how to fix it - and if not, why not.
>>
>> Regards,
>> Edgar
>>
>> FYI:
>> mod_fcgid 2.3.5
>> with httpd 2.2.15
>> on CentOS 5.4 x64
>> built from source with gcc 4.2.4
>>
>
