Re: [mod-security-users] Retry-After header not being set?

[Jamie B. <ja...@ib...>]

Hi Reindl

> your expectation is simply wrong
> when you use a PHP script for error-pages the default response is 200
because you override the error

This is not true. I have the ErrorDocument for a 429 set to a very basic
PHP page which outputs the unique request ID for diagnostic purposes and
the response code is 429, not 200. The PHP script does not do anything
else.

Further, headers I am setting in Apache are in that same response:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
X-UA-Compatible: IE=edge
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
...

If I add Header always set Retry-After "10" in the virtual host block,
that header is in the response for all requests (including those handled
by PHP) and for 200 and 429 responses.

The part that seems not to work is the condition based on the environment
variable in combination with processing the PHP file.

Jamie

-----Original Message-----
From: Reindl Harald <h.r...@th...>
Sent: 17 February 2022 23:07
To: mod...@li...
Subject: Re: [mod-security-users] Retry-After header not being set?



Am 18.02.22 um 00:02 schrieb Jamie Burchell:
> No, I'm not sending the headers from there, but I could

you must

> I expected the
> headers set by Apache to work though, since the HSTS header works.

your expectation is simply wrong

when you use a PHP script for error-pages the default response is 200
because you override the error

rule of thumbs: don't use custom error pages (with dynamic scripts) for
anything else but 403/404

and for rate-limits (which shouldn't be handeled in the application layer
to begin with) it's pretty nonsense to add the burden of a dynamic script

> -----Original Message-----
> From: Reindl Harald <h.r...@th...>
> Sent: 17 February 2022 21:26
> To: mod...@li...
> Subject: Re: [mod-security-users] Retry-After header not being set?
>
>
>
> Am 17.02.22 um 21:35 schrieb Jamie Burchell:
>> Hi Andrew
>>
>> Thanks for taking the time to help me. I have narrowed the header
>> issue down. If I remove:
>>
>> ErrorDocument 429 /error.php
>>
>> The default Apache error document is used, and the header is in the
>> response. It seems that somehow it is being removed when I'm passing
>> the processing off to PHP-FPM
>
> does your "error.php" send the correct header?


_______________________________________________
mod-security-users mailing list
mod...@li...
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
http://www.modsecurity.org/projects/commercial/rules/
http://www.modsecurity.org/projects/commercial/support/