docs: clarify when filter regexes must be quoted - #8346
Open
citizen204 wants to merge 2 commits into
Open
Conversation
…its configured password Fixes mitmproxy#8138
lups2000
requested changes
Aug 4, 2026
Comment on lines
730
to
745
|
|
||
| def load_pem_private_key(data: bytes, password: bytes | None) -> rsa.RSAPrivateKey: | ||
| """ | ||
| like cryptography's load_pem_private_key, but silently falls back to not using a password | ||
| like cryptography's load_pem_private_key, but falls back to not using a password | ||
| if the private key is unencrypted. | ||
| """ | ||
| try: | ||
| return serialization.load_pem_private_key(data, password) # type: ignore | ||
| except TypeError: | ||
| if password is not None: | ||
| logger.warning( | ||
| "A password was configured for a private key that is not encrypted. " | ||
| "Ignoring the password and loading the key without one." | ||
| ) | ||
| return load_pem_private_key(data, None) | ||
| raise |
Member
There was a problem hiding this comment.
remove this unrelated stuff please
| assert cert.crl_distribution_points == crls | ||
|
|
||
|
|
||
| class TestLoadPemPrivateKey: |
Comment on lines
+17
to
+20
| - Unquoted regexes must not contain parentheses, whitespace, or the `~`, `'`, `"` | ||
| characters, as these are used for grouping and quoting. A regex containing any | ||
| of these, e.g. one using `(...)` for grouping, must be wrapped in quotes - | ||
| `~u "get(Info|Routers)"` - or it will be parsed as multiple filter expressions. |
Member
There was a problem hiding this comment.
Suggested change
| - Unquoted regexes must not contain parentheses, whitespace, or the `~`, `'`, `"` | |
| characters, as these are used for grouping and quoting. A regex containing any | |
| of these, e.g. one using `(...)` for grouping, must be wrapped in quotes - | |
| `~u "get(Info|Routers)"` - or it will be parsed as multiple filter expressions. | |
| - Regexes containing parentheses, whitespace, or the `~`, `'`, `"` characters must be quoted because these characters are reserved by the filter expression syntax. Otherwise, the expression may be parsed differently or rejected. For example, use ~u "get(Info|Routers)". |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
#7715 reports that an unquoted regex containing grouping parentheses, e.g.
~u get(Info|Routers), is silently misparsed:(and)are reserved characters used by the boolean-grouping grammar inmitmproxy/flowfilter.py(unicode_words = pp.CharsNotIn("()~'\"" + DEFAULT_WHITE_CHARS)), so the filter actually becomes~u get & ~u "Info|Routers"rather than a single regex match. I confirmed this by parsing several expressions directly withmitmproxy.flowfilter.parse():~u get(Info|Routers)->url matches /get/i and url matches /Info|Routers/i(broken)~u "get(Info|Routers)"->url matches /get(Info|Routers)/i(correct, quoted)~u get|other/~u get&other/~u get!otherall parse fine unquoted, since|,&,!are only treated as operators when surrounded by whitespace.~u foo~barand~u it'salso fail unquoted, since~and'are likewise reserved.Redesigning the grammar to disambiguate regex-parens from grouping-parens is a real design trade-off a maintainer should own, so rather than touch the parser this PR only fixes the documentation, which currently states "Regexes can be specified as quoted strings" without mentioning that some regexes must be quoted to parse correctly - contradicting user expectations as described in the issue.
Fixes #7715
Changes
docs/src/content/concepts/filters.md: document that unquoted regexes must avoid parentheses, whitespace, and the~,',"characters, and must be quoted otherwise (with a corrected example using the exact case from the issue)