Hi HAProxy team! I found several obvious typos in the documentation.
-- >8 -- s/elvoved/evolved s/performend/performed s/importnat/important s/sharedd/shared s/eveyone/everyone No backport needed. --- doc/coding-style.txt | 2 +- doc/configuration.txt | 4 ++-- doc/internals/api/buffer-list-api.txt | 2 +- doc/intro.txt | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/doc/coding-style.txt b/doc/coding-style.txt index 02a55f513..244d7a0be 100644 --- a/doc/coding-style.txt +++ b/doc/coding-style.txt @@ -3,7 +3,7 @@ A number of contributors are often embarrassed with coding style issues, they don't always know if they're doing it right, especially since the coding style -has elvoved along the years. What is explained here is not necessarily what is +has evolved along the years. What is explained here is not necessarily what is applied in the code, but new code should as much as possible conform to this style. Coding style fixes happen when code is replaced. It is useless to send patches to fix coding style only, they will be rejected, unless they belong to diff --git a/doc/configuration.txt b/doc/configuration.txt index fd6a68ad7..8c54b44a7 100644 --- a/doc/configuration.txt +++ b/doc/configuration.txt @@ -5718,7 +5718,7 @@ It is possible to chain a TCP frontend to an HTTP backend. It is pointless if only HTTP traffic is handled. But it may be used to handle several protocols within the same frontend. In this case, the client's connection is first handled as a raw tcp connection before being upgraded to HTTP. Before the upgrade, the -content processings are performend on raw data. Once upgraded, data is parsed +content processings are performed on raw data. Once upgraded, data is parsed and stored using an internal representation called HTX and it is no longer possible to rely on raw representation. There is no way to go back. @@ -5736,7 +5736,7 @@ HTTP/2 upgrade, applicative streams are distinct and all frontend rules are evaluated systematically on each one. And as said, the first stream, the TCP one, is destroyed, but only after the frontend rules were evaluated. -There is another importnat point to understand when HTTP processings are +There is another important point to understand when HTTP processings are performed from a TCP proxy. While HAProxy is able to parse HTTP/1 in-fly from tcp-request content rules, it is not possible for HTTP/2. Only the HTTP/2 preface can be parsed. This is a huge limitation regarding the HTTP content diff --git a/doc/internals/api/buffer-list-api.txt b/doc/internals/api/buffer-list-api.txt index 9f0e2e4cf..194945135 100644 --- a/doc/internals/api/buffer-list-api.txt +++ b/doc/internals/api/buffer-list-api.txt @@ -5,7 +5,7 @@ The buffer list API allows one to share a certain amount of buffers between multiple entities, which will each see their own as lists of buffers, while -keeping a sharedd free list. The immediate use case is for muxes, which may +keeping a shared free list. The immediate use case is for muxes, which may want to allocate up to a certain number of buffers per connection, shared among all streams. In this case, each stream will first request a new list for its own use, then may request extra entries from the free list. At any diff --git a/doc/intro.txt b/doc/intro.txt index 27d5f7e69..ccf0c06d7 100644 --- a/doc/intro.txt +++ b/doc/intro.txt @@ -1693,7 +1693,7 @@ A small team of trusted developers will receive it and will be able to propose a fix. We usually don't use embargoes and once a fix is available it gets merged. In some rare circumstances it can happen that a release is coordinated with software vendors. Please note that this process usually messes up with -eveyone's work, and that rushed up releases can sometimes introduce new bugs, +everyone's work, and that rushed up releases can sometimes introduce new bugs, so it's best avoided unless strictly necessary; as such, there is often little consideration for reports that needlessly cause such extra burden, and the best way to see your work credited usually is to provide a working fix, which will -- Egor Shestakov egor ascii(0x40) ved1 ascii(0x2E) me
