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

December monthly meeting agenda #972

Closed
spartantri opened this Issue Nov 27, 2017 · 5 comments

Comments

Projects
None yet
5 participants
@spartantri
Copy link
Collaborator

spartantri commented Nov 27, 2017

  • CRS is about to win an award; this will bring some media coverage hopefully. We should use that new momentum
  • Handling of case (?:in)?sensitive items (see below for additional infos)
  • We need a plan to reduce open issues. The way it is now gives a bad impression
  • PR #978 : Update date and add badges
  • PR #977 : Travis: fail if apache fails
  • PR #970 : 933131: insensitive tests
  • PR #957 : 942370 : rule split
  • PR #953 : ftw: configurable time stamp format
  • PR #926 - #949 : FTW test PRs by @azhao155
  • PR #905 : fix for duplicated header bypass
  • PR #899 : Rule exclusion packages for dokuwiki and nextcloud (no progres on the side of the contributor)
  • PR #896 : Command substitution backquoted version support
  • PR #881 : REQUEST-944-APPLICATION-ATTACK-JAVA.conf Feature Request

Case sensitive items (additional infos)

There are rules with different approaches

  • Ignore cases by converting all to lowercase/uppercase in a transform (t:lowercase)
  • Ignore cases by using case insensitive regex (?i)
  • Case sensitive rules using all uppercase [good for http methods bad for most other stuff] (?:GET|POST)
  • Case sensitive rules using regex with both cases (?:[eEiIoOuUyY]acute)
  • Which one is faster?
  • Benchmarks?
  • Which one to use on which circumstance

It maybe easier to use t:lowercase and convert all the regex to lowercase and add a warning in CONTRIBUTING.md

@csanders-git

This comment has been minimized.

Copy link
Collaborator

csanders-git commented Nov 27, 2017

i'm actually not sure about this. My gut says that the transform will be faster but if the regex engine is already booted up for something different the performance is probably negligible

@dune73

This comment has been minimized.

Copy link
Collaborator

dune73 commented Nov 27, 2017

It's probably worth to test in detail before we chance anything.

@fgsch

This comment has been minimized.

Copy link
Collaborator

fgsch commented Nov 27, 2017

My gut feeling says the opposite, the regexp should be faster or equal.

Also there is no need to pre-convert the whole input to lowercase if it's not going to match further down the line. For large inputs this might be considerable.

It'd be great to see some benchmarks though.

@lifeforms

This comment has been minimized.

Copy link
Collaborator

lifeforms commented Dec 4, 2017

Handling of case (?:in)?sensitive items - To set a standard for future development, we need to know which way has better performance. @spartantri is going to try to do some benchmarks on Apache, so we can revisit the issue next month.

@lifeforms

This comment has been minimized.

Copy link
Collaborator

lifeforms commented Dec 4, 2017

Open issues: Yeah, there are many open issues.. All reviewers should try to look at their assigned issues if they can. Many new PRs are about the test suite, which is not working yet for everyone. These issues fortunately seem small. They are assigned to @csanders-git.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment