On 22 October 2014 13:51, Yehuda Katz <yeh...@ymkatz.net> wrote:
> On Wed, Oct 1, 2014 at 2:19 PM, Eric Covener <cove...@gmail.com> wrote:
>
>>
>> On Wed, Oct 1, 2014 at 2:16 PM, Eric Covener <cove...@gmail.com> wrote:
>>
>>> To me, this does not exonerate mod_php, it implicates it. I suspect
>>> your source code is served because PHP swallowed the LimitRequestBody and
>>> then passed control back to Apache. I'm fairly certain I responded to you
>>> privately with similar information already.
>>
>>
>> I should add that I don't understand your scenario completely, where the
>> file is not processed. I think my own test result was the same as Yehuda
>> ITT which is not the same as what I just described with the default handler
>> taking over.
>>
>
> 1. Is this result (PHP executed) still a bug (could be in mod_php)? If a
> 413 comes up, shouldn't no other content be returned?
> I am considering setting up a new VM to do some testing, but I want to
> make sure this is not the expected behavior (whether the PHP is executed or
> not).
>
> 2. Is there another module that hooks in with a similar way to mod_php
> that might also show this behavior (mod_lua for example)?
>
FWIW, I noted similar behaviour in implementing mod_wsgi many years ago.
Since then I have code in mod_wsgi in the handler before anything is done
which specifically does:
/*
* Check to see if the request content is too large if the
* Content-Length header is defined then end the request here. We do
* this as otherwise it will not be done until first time input data
* is read in by the application. Problem is that underlying HTTP
* output filter will also generate a 413 response and the error
* raised from the application will be appended to that. The call to
* ap_discard_request_body() is hopefully enough to trigger sending
* of the 413 response by the HTTP filter.
*/
lenp = apr_table_get(r->headers_in, "Content-Length");
if (lenp) {
char *endstr;
apr_off_t length;
if (wsgi_strtoff(&length, lenp, &endstr, 10)
|| *endstr || length < 0) {
wsgi_log_script_error(r, apr_psprintf(r->pool,
"Invalid Content-Length header value of '%s' was "
"supplied.", lenp), r->filename);
return HTTP_BAD_REQUEST;
}
limit = ap_get_limit_req_body(r);
if (limit && limit < length) {
ap_discard_request_body(r);
return OK;
}
}
So in the case of mod_wsgi it wasn't that the source code was being
appended, but that any error response from the hosted Python WSGI
application, generated in reaction to the reading of the request content
failing because of the length check by the input filter, that got appended
to the end of the 413 error response that the HTTP filter had already
caused to be delivered back.
Graham
