-
Notifications
You must be signed in to change notification settings - Fork 21
docs(known-issues): document early blocking #222
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Felipe Zipitria <felipe.zipitria@owasp.org>
Deploying crs-documentation with
|
Latest commit: |
9f10c39
|
Status: | ✅ Deploy successful! |
Preview URL: | https://ca8ecd58.documentation-km5.pages.dev |
Branch Preview URL: | https://chore-add-early-blocking-doc.documentation-km5.pages.dev |
Co-authored-by: Xhoenix <86168235+Xhoenix@users.noreply.github.com>
> **Enable early execution of phase 1 rules** | ||
> By default, ModSecurity does **not** activate this flag. Phase 1 rules run **after** the request headers are fully read. This flag allows certain phase 1 rules to trigger *earlier*, potentially before the full header set is available. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is the wrong way around. @airween? Didn't the issue say they used --disable-request-early
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, @theseion is right. I think we should suggest don't use --disable-request-early
flag.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ugh. Is it just the name, or the behavior completely changes? Can you point me to the docs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just found this one:
Starting with ModSecurity 2.7.0 there are a few important configuration options
- --enable-request-early - On ModSecurity 2.6 phase one has been moved to phase 2 hook, if you want to play around it use this option.
But in configure.ac, the logic is in opposite direction:
if test "$enableval" != "no"; then
request_early="-DREQUEST_EARLY"
MODSEC_EXTRA_CFLAGS="$MODSEC_EXTRA_CFLAGS $request_early"
else
request_early=
fi
],
[
request_early='-DREQUEST_EARLY'
The logic:
- if the user passes this option, and the value is not
no
(which equals with--disable-request-early
, then feature will be turned ON - if the user does not pass this option, then the build script assumes it's necessary and will be turned ON
what
Fixes #221