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.
The raw HTTP header buffer had to be registered one state past the header state. The reason is that htp reports progress as soon as a block starts: request_progress reaches HEADERS right after the request line and TRAILER at the zero-length chunk, so a detection round at HEADERS can run while the block is still arriving. For a byte buffer that shows - negated content or a within: relative match would decide on a truncated block. HEADERS + 1 avoided it by accident of numbering, BODY being what htp reaches once the block is done. Make completion an event instead of inferring it from numbering. htp's REQUEST_HEADERS and RESPONSE_HEADERS hooks only ran in test builds, which is why production had nothing to key on; they now run always and are bound through the C API. Suricata marks per transaction that a block ended, from those hooks and from the trailer hooks that already ran, and the four HTTP/1 block buffers - http.header.raw, http.trailer, http.trailer.raw and http.trailer_names - report no data until then. Each registers at the state where its content completes, and no state offset remains in the tree. A block that ends because the stream closes needs no special case: htp's closure handling advances progress past the block state and runs the trailer hook, so the gate opens on its own and the partial content is inspected as it is today. Suricata-Verify tests/http1-raw-header- truncated covers both directions. htp progress values, and the transaction lifecycle built on them, are left alone: delaying those changes when firewall decisions become definitive and fails the ruletype-firewall state hook tests. Ticket: #8256. |
5 days ago | |
|---|---|---|
| .. | ||
| 3rd-party-integration | ||
| _static | ||
| appendix | ||
| capture-hardware | 5 months ago | |
| configuration | 2 months ago | |
| devguide | 3 weeks ago | |
| file-extraction | ||
| firewall | 5 days ago | |
| install | ||
| ips | ||
| licenses | ||
| lua | 5 days ago | |
| manpages | 5 months ago | |
| output | 3 weeks ago | |
| partials | 3 weeks ago | |
| performance | 5 months ago | |
| plugins | ||
| protocols | ||
| reputation | ||
| rule-management | ||
| rules | 5 days ago | |
| upgrade | ||
| .gitignore | ||
| Makefile.am | ||
| Makefile.sphinx | ||
| README.md | ||
| acknowledgements.rst | ||
| command-line-options.rst | ||
| conf.py | 6 months ago | |
| convert.py | ||
| docutils.conf | ||
| generate-evedoc.sh | ||
| index.rst | ||
| initscripts.rst | ||
| install.rst | 2 months ago | |
| make-sense-alerts.rst | ||
| public-data-sets.rst | ||
| quickstart.rst | 4 months ago | |
| requirements.txt | ||
| security.rst | ||
| support-status.rst | ||
| unix-socket.rst | ||
| upgrade.rst | 5 days ago | |
| verifying-source-files.rst | ||
| what-is-suricata.rst | ||
README.md
Suricata User Guide
This directory contains the Suricata Guide. The Suricata Developer's guide is included as a chapter of the Guide. The Sphinx Document Generator is used to build the documentation. For a primer os reStructuredText see the reStructuredText Primer.
Verifying Changes
There are a number of output formats to choose from when making the source documentation locally (e.g. html, pdf, man).
The documentation source can be built with make -f Makefile.sphinx html. Substitute the 'html' word for desired output format.
There are different application dependencies based on the output desired.