Suricata

Hello Suricata maintainers,

I am asking about a reproducible detection-behavior difference observed in a local synthetic test. This is not an assertion of a vulnerability or production impact.

1. Observation
   For synthetic HTTP case SID 43541, the recorded test had eight BODY sections, but [1;3mfile_data[0m was unavailable at the target rule point. Switching the rule to HEADER still left the [1;3mfile_data[0m buffer length at zero. In the archived comparison, changing the registered section together with the empty-file predicate made the path available and changed the result from no alert to an alert. Could you clarify whether this section/buffer scheduling is expected, and whether a focused Suricata-Verify case would be useful?

1. Reproducer and environment
   Attached ZIP contains the synthetic PCAP, target rule, and runtime request. The recorded experiment used an offline container with networking disabled and [1;3m/etc/suricata/suricata.yaml[0m; image digest: [1;3msha256:f5dbd5fc59f9d277f987e3e4647bd019f90c042664b918a96156fda9dba7c29f[0m. PCAP/rule hashes are in the runtime request. This is a historical controlled result dated 2026-09-17; the ZIP was assembled 2026-10-25 and has not itself been independently replayed. The image is not included and may only be locally available.

Traffic is synthetic and was tested offline only; no production system or third-party target was involved. This report asks for maintainer clarification, not a vulnerability determination.

Thank you.