Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
i/p/patterns: disallow /./ and /../ in path patterns (#14774)
* i/p/patterns: disallow /./ and /../ in path patterns Since patterns like /foo/./bar don't match paths paths like /foo/bar, throw an error if the client tries to reply or create a rule with such a construction clearly in the pattern. That is, if the pattern contains `/./` or `/../`, or if it ends with `/.` or `/..`. Notably, we do this on the raw pattern string, similarly to how we validate that the pattern begins with a `/`: we don't consider whether all alts in a leading group happen to start with `/`, we simply throw an error if the first character is not `/`. In this case, we take a more lenient (but similarly lazy) approach: if there's a literal `/./` or `/../`, or trailing `/.` or `/..`, then an error is thrown. As long as there's something interrupting the `/` or end of the pattern string (e.g. a group), we consider that fine. For example, we allow `/foo/.{,bar}` even though technically this renders to the variants `/foo/.` and `/foo/.bar`, where the former is undesirable. We may reconsider this in the future, but checking whether any rendered variant contains `/./` or `/../` in general requires fully rendering each variant and checking each one, which we do not do at parse time, and one nearly always has at least one pattern which is capable of matching something valid (an exception being the pattern `/foo/.{,}`, for example). But the user must fairly deliberately shoot themself in the foot to end up in that situation. Again, the worst case if a pattern which is "bad" in this way gets past validation is that we end up with a path pattern which is incapable of matching any paths. This is undesirable, but not problematic. Signed-off-by: Oliver Calder <[email protected]> * i/p/requestprompts: clarify comment for the relative path regexp Co-authored-by: Zeyad Yasser <[email protected]> --------- Signed-off-by: Oliver Calder <[email protected]> Co-authored-by: Zeyad Yasser <[email protected]>
- Loading branch information