From dev-return-68967-apmail-httpd-dev-archive=httpd.apache.org@httpd.apache.org Tue Jul 06 12:58:04 2010 Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 85816 invoked from network); 6 Jul 2010 12:58:04 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 6 Jul 2010 12:58:04 -0000 Received: (qmail 30341 invoked by uid 500); 6 Jul 2010 12:58:02 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 28969 invoked by uid 500); 6 Jul 2010 12:57:59 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 28960 invoked by uid 99); 6 Jul 2010 12:57:58 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Jul 2010 12:57:58 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [217.72.192.242] (HELO fmmailgate04.web.de) (217.72.192.242) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Jul 2010 12:57:49 +0000 Received: from mwmweb044 ( [172.20.18.53]) by fmmailgate04.web.de (Postfix) with ESMTP id 24A0C680FBF2 for ; Tue, 6 Jul 2010 14:56:59 +0200 (CEST) Received: from [217.92.147.99] by mwmweb044 with HTTP; Tue Jul 06 14:56:59 CEST 2010 Date: Tue, 6 Jul 2010 14:56:59 +0200 (CEST) From: Edgar Frank To: dev@httpd.apache.org Message-ID: <1677253231.1010974.1278421019136.JavaMail.fmail@mwmweb044> Subject: Problem with mod_fcgid handling ErrorDocuments MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: normal Sensitivity: Normal X-Provags-ID: V01U2FsdGVkX18b0lg0pfhX+4EpZf9IG4i2Pq7v8F+k9UyvsEosJeUm0unOqsQK9/6s 5Kz3RZn8NAAn1HQBR6QhVWffU7dGeG8t X-Virus-Checked: Checked by ClamAV on apache.org 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". 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?) 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