mirror of https://github.com/OISF/suricata
You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
fd4c197f45
An HTTP/2 stream puts its trailers in a HEADERS block after the body. There was no state for it, so detection had nothing to hook: the block was merged into the header buffers, where the header state had already been declared complete. gRPC streams, which always end with such a block, could not be matched at all. Add HTTP2ProgTrailers between the data and the closed state, and mark the frames of a trailer block. Marking keys on the header section having completed in that direction, not on the progress value and not on body data: RFC 9113 permits a trailer section behind a message that sent no DATA frames at all. A second block that only follows an informational response is not a trailer, so a to-client block completes the header section only with a non-1xx :status, and a CONTINUATION takes the classification of the block it continues, not the state the direction reached since. A state inserted into a shipped protocol defaults to drop:flow in firewall mode, which would block every stream that has trailers the moment this builds. So a parser can now describe its sub-states fully - completion state and the built-in policy of each state - instead of AppLayerParserGetSubStateCompletion guessing from hard coded numbers. The trailer states register accept:hook, so behaviour only changes for deployments that opt in; the generic drop:flow still applies to the states the protocol has always had. Ticket: #8256. |
5 days ago | |
|---|---|---|
| .. | ||
| firewall-design.rst | 5 days ago | |
| firewall-example.rst | 3 weeks ago | |
| firewall-stats.rst | 5 months ago | |
| fw-pipeline.png | ||
| index.rst | 3 weeks ago | |
| ssh-state-migration.rst | 3 weeks ago | |
| tls-state-migration.rst | 3 weeks ago | |
