Closed franbuehler closed 1 month ago
Looks good but I think i'd probably modify the pattern to add (?i)
so it also works if someone adds a content type to tx.allowed_request_content_type
using different cases.
What do you think?
Hi @fgsch Thanks for your suggestions. I will have a look at it asap.
Looks good but I think i'd probably modify the pattern to add
(?i)
so it also works if someone adds a content type totx.allowed_request_content_type
using different cases.What do you think?
SecRule TX:0 "!@rx ^(?i)%{tx.allowed_request_content_type}$"
I tested this and it doesn't work. I didn't debug it, but I think it's because the (?i)
is not followed by a regex, but a variable?? I don't know.
I could modify the PR so that the t:lowercase
doesn't belong to the chain starter rule, but to the second rule.
What do you think?
The CRS Content-Type check is case sensitive. But request headers should be case insensitive. This PR adds
t:lowercase
to the rule 920420 that compares the sent Content-Type request header with a list of Content-Types defined in an initialization rule 900220.This PR also adds a regression test for the new allowed Content-Type
multipart/related
from PR #1721 and a new regression test with a Content-Type starting with an uppercase letter.