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
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
On Wed, Oct 01, 2014 at 02:16:17PM -0400, Eric Covener wrote:
The default handler (static file handler) is a fall-through, and there is
not currently a way to tell it NOT to respond for something because a
configured module unexpectedly passed control back. It is a relatively
easy opt-in
Am 02.10.2014 um 22:36 schrieb Joe Orton:
On Wed, Oct 01, 2014 at 02:16:17PM -0400, Eric Covener wrote:
The default handler (static file handler) is a fall-through, and there is
not currently a way to tell it NOT to respond for something because a
configured module unexpectedly passed control
On Thu, Oct 2, 2014 at 5:06 PM, Reindl Harald h.rei...@thelounge.net
wrote:
however, control that by modsec gives you even the option to
select the status code without leak source code - if a module
can do that why not the core itself unconditional?
The core or any other module could check
Am 03.10.2014 um 00:09 schrieb Eric Covener:
On Thu, Oct 2, 2014 at 5:06 PM, Reindl Harald h.rei...@thelounge.net wrote:
however, control that by modsec gives you even the option to
select the status code without leak source code - if a module
can do that why not the core itself
On Thu, Oct 2, 2014 at 7:02 PM, Reindl Harald h.rei...@thelounge.net
wrote:
Am 03.10.2014 um 00:09 schrieb Eric Covener:
On Thu, Oct 2, 2014 at 5:06 PM, Reindl Harald h.rei...@thelounge.net
wrote:
however, control that by modsec gives you even the option to
select the status
Am 03.10.2014 um 02:18 schrieb Eric Covener:
On Thu, Oct 2, 2014 at 7:02 PM, Reindl Harald h.rei...@thelounge.net wrote:
Am 03.10.2014 um 00:09 schrieb Eric Covener:
On Thu, Oct 2, 2014 at 5:06 PM, Reindl Harald h.rei...@thelounge.net
wrote:
however, control that
Am 16.09.2013 um 19:33 schrieb Yehuda Katz:
I can sort-of confirm this.
Apache 2.4.3 on Windows 7 x64 (ApacheLounge build)
For me, the PHP is executed, not displayed.
Stock configuration with mod_php and only this added:
Location /phpinfo.php
LimitRequestBody 1
/Location
The built
On Wed, Oct 1, 2014 at 1:05 PM, Reindl Harald h.rei...@thelounge.net
wrote:
mod_security and
SecRequestBodyLimit works as expected
blocking the request - so it hardly is a bug in mod_php
which should not be called at all if LimitRequestBody
takes action
SecRequestBodyLimit reads the
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
Am 01.10.2014 um 20:19 schrieb Eric Covener:
On Wed, Oct 1, 2014 at 2:16 PM, Eric Covener cove...@gmail.com
mailto: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
On Wed, Oct 1, 2014 at 2:24 PM, Reindl Harald h.rei...@thelounge.net
wrote:
i don't know what happens internally
That's what's on-topic for the development list.
just that SecRequestBodyLimit opens a large security hole
because on just needs to send large data to any script
on the
Am 01.10.2014 um 20:36 schrieb Eric Covener:
On Wed, Oct 1, 2014 at 2:24 PM, Reindl Harald h.rei...@thelounge.net
mailto:h.rei...@thelounge.net wrote:
i don't know what happens internally
That's what's on-topic for the development list
agreed - but ship source code to a client is
14 matches
Mail list logo
