Suricata

When a client uses Expect: 100-continue and the server answers a bare 100 Continue, the HTTP parser rewinds the same response tx at the empty line ending the 100's headers: headers cleared, progress back from HEADERS to LINE - but neither the tx's stat-code byte buffer (still 100) nor the detection engine's per-tx bookkeeping is reset. On ordinary, spec-compliant traffic this yields a false positive and a false negative:

• False positive (double alert). The 100 line commits at HEADERS; its final run matches the 100 buffer once and stores per-tx detect_progress (LINE + 1). The rewind leaves the stale 100 buffer with the tx at LINE; when the final 200's line arrives the engine re-runs non-terminally and matches it again - the 100 line alerts twice.
• False negative (the bypass). The final 200 is parsed on the same tx and refreshes both the buffer and the numeric status - the http log correctly records 200. But the stale detect_progress survives: when the tx reaches COMPLETE the prefilter sees detect_progress > tx_min_progress and skips the stat-code engine for the tx entirely - the final response's stat code is never inspected, so any http.stat_code rule on it is dead for such flows.

The numeric status is not the detection input, but it triggers the rewind itself (the parser keys on 100 at the empty line) - that is what keeps the final 200 on the poisoned tx. Scope: only the stat-code buffer - the final response's headers/body and request-side keywords still detect normally. IPS mode hits this for any 100-continue exchange; NIDS mode when the 100 line commits in its own parse cycle (client auto-ACKs the 100 response). SV MR 9 reproduces both end-to-end.

I wonder if we should create a new tx instead of doing the rewind. Suricata generally expects the tx state to be monotonic.