mirror of
https://git.haproxy.org/git/haproxy.git/
synced 2025-09-21 05:41:26 +02:00
3d4438484a
There are a lot of H2 events which are not invalid from a protocol perspective but which are yet anomalies, especially when repeated. They can come from bogus or really poorly implemlented clients, as well as purposely built attacks, as we've seen in the past with various waves of attempts at abusing H2 stacks. In order to better deal with such situations, it would be nice to be able to sort out what is correct and what is not. There's already the HTTP error counter that may even be updated on a tracked connection, but HTTP errors are something clearly defined while there's an entire scope of gray area around it that should not fall into it. This patch introduces the notion of "glitches", which normally correspond to unexpected and temporary malfunction. And this is exactly what we'd like to monitor. For example a peer is not misbehaving if a request it sends fails to decode because due to HPACK compression it's larger than a buffer, and for this reason such an event is reported as a stream error and not a connection error. But this causes trouble nonetheless and should be accounted for, especially to detect if it's repeated. Similarly, a truncated preamble or settings frame may very well be caused by a network hiccup but how do we know that in the logs? For such events, a glitch counter is incremented on the connection. For now a total of 41 locations were instrumented with this and the counter is reported in the traces when not null, as well as in "show sess" and "show fd". This was done using a new function, "h2c_report_glitch()" so that it becomes easier to extend to more advanced processing (applying thresholds, producing logs, escalating to connection error, tracking etc). A test with h2spec shows it reported in 8545 trace lines for 147 tests, with some reaching value 3 in a same test (e.g. HPACK errors). Some places were not instrumented, typically anything that can be triggered on perfectly valid activity (received data after RST being emitted, timeouts, etc). Some types of events were thought about, such as INITIAL_WINDOW_SIZE after the first SETTINGS frame, too small window update increments, etc. It just sounds too early to know if those are currently being triggered by perfectly legit clients. Also it's currently not incremented on timeouts so that we don't do that repeatedly on short keep-alive timeouts, though it could make sense. This may change in the future depending on how it's used. For now this is not exposed outside of traces and debugging.
The HAProxy documentation has been split into a number of different files for ease of use. Please refer to the following files depending on what you're looking for : - INSTALL for instructions on how to build and install HAProxy - BRANCHES to understand the project's life cycle and what version to use - LICENSE for the project's license - CONTRIBUTING for the process to follow to submit contributions The more detailed documentation is located into the doc/ directory : - doc/intro.txt for a quick introduction on HAProxy - doc/configuration.txt for the configuration's reference manual - doc/lua.txt for the Lua's reference manual - doc/SPOE.txt for how to use the SPOE engine - doc/network-namespaces.txt for how to use network namespaces under Linux - doc/management.txt for the management guide - doc/regression-testing.txt for how to use the regression testing suite - doc/peers.txt for the peers protocol reference - doc/coding-style.txt for how to adopt HAProxy's coding style - doc/internals for developer-specific documentation (not all up to date)