Conversation
Ticket: 2487
instead of a single progress. Will help for keywords such as http.header which can act on headers and trailers progress
reuse generic DetectEngineInspectBufferGeneric
even if the http request does not come into one packet and the http_header is not the fast pattern
catenacyber
requested review from
jasonish,
jufajardini and
victorjulien
as code owners
| int sig_list = 0; | ||
| if (list_id == app_state_list_id) | ||
| sig_list = app_state_list_id; | ||
| // TODO check if we need to pass max_progress |
There was a problem hiding this comment.
Advices here before I dive ?
| uint16_t sm_list; | ||
| uint16_t sm_list_base; /**< base buffer being transformed */ | ||
| int16_t progress; | ||
| // TODO move to u8 see BUG_ON vs 48 |
There was a problem hiding this comment.
Was there a reason for signed i16 ?
There was a problem hiding this comment.
iirc previously progress was an int and this was just an attempt to compress it. Progress should probably be converted to u8
|
I would like to see an explanation in the commit of what max_progress does and an explanation of what problem it solves (concrete issue analysis) |
Just an exploratory draft here... As said in the previous PR :
Without this max_progress, we would think a signature with Should I create a ticket for the http_header vs trailer bug ? (or desired behavior) |
|
ERROR: ERROR: QA failed on SURI_TLPR1_alerts_cmp. Pipeline = 29327 |
|
Something cleaner to start in #14717 |
3 participants
Link to ticket: https://redmine.openinfosecfoundation.org/issues/
https://redmine.openinfosecfoundation.org/issues/2487
Describe changes:
SV_BRANCH=OISF/suricata-verify#2860
#14621 with more...
Needs to :