detect/http: fix progress for headers keywords #12056
Conversation
Ticket: 7326 Having a lower progress than one where we actually can get occurences of the multibuffer made prefilter bail out too early, not having found a buffer in the multi-buffer that matiched the prefilter. For example, we registered http_request_header with progress 0 instad of progress HTP_REQUEST_HEADERS==2, and if the first packet had only the request line, we would consider that signatures with http_request_header as prefilter/fast_pattern could not match for this transaction, even if they in fact could have a later packet with matching headers. Hence, we got false negatives, if http.request_header or http.response_header was used as fast pattern, and if the request or response came in multiple packets, and the first of these packets did not have enough data (like only http request line), and the next packets did have the matching data.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #12056 +/- ##
==========================================
- Coverage 83.42% 83.41% -0.02%
==========================================
Files 910 910
Lines 257642 257642
==========================================
- Hits 214949 214913 -36
- Misses 42693 42729 +36
Flags with carried forward coverage won't be shown. Click here to find out more. |
|
Information: QA ran without warnings. Pipeline 23206 |
|
@victorjulien Should we have the generic fix of |
I don't understand the question. Can you explain more? |
|
The prototype is like
Should we change the prototype of |
Hmmm I don't know w/o studying the code more. I guess it can be investigated. |
I don't know after having studied the code. |
|
Merged in #12088, thanks! |
Link to ticket: https://redmine.openinfosecfoundation.org/issues/
https://redmine.openinfosecfoundation.org/issues/7326
Describe changes:
SV_BRANCH=OISF/suricata-verify#2094
Should we have the generic fix of
DetectAppLayerMultiRegisterusing only one tx progress ?#11977 with yet longer improved commit message