RepoMirrors
/
haproxy
mirror of http://git.haproxy.org/git/haproxy.git/
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

DOC: internals: Fix spelling errors in filters.txt

This commit is contained in:
Miroslav Zagorac 2020-03-26 20:45:04 +01:00 committed by Willy Tarreau
parent b428517fee
commit d80f5c0d0c
1 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
doc/internals/filters.txt
View File

@ -54,7 +54,7 @@ places, mainly around channel analyzers. Their purpose is to allow filters to
be involved in the data processing, from the stream creation/destruction to
the data forwarding. Depending of what it should do, a filter can implement all
or part of these callbacks. For now, existing callbacks are focused on
streams. But futur improvements could enlarge filters scope. For example, it
streams. But future improvements could enlarge filters scope. For example, it
could be useful to handle events at the connection level.
In HAProxy configuration file, a filter is declared in a proxy section, except
@ -84,7 +84,7 @@ filters are also chained, frontend ones called first. Even if the filters
processing is serialized, each filter will bahave as it was alone (unless it was
developed to be aware of other filters). For all that, some constraints are
imposed to filters, especially when data exchanged between the client and the
server are processed. We will dicuss again these constraints when we will tackle
server are processed. We will discuss again these constraints when we will tackle
the subject of writing a filter.
@ -122,11 +122,11 @@ The list of available filters is reported by 'haproxy -vv':
Multiple filter lines can be used in a proxy section to chain filters. Filters
will be called in the declaration order.
Some filters can support implicit declarartions in certain circumstances
Some filters can support implicit declarations in certain circumstances
(without the filter line). This is not recommended for new features but are
useful for existing ones moved in a filter, for backward compatibility
reasons. Implicit declarartions are supported when there is only one filter used
on a proxy. When several filters are used, explicit declarartions are mandatory.
reasons. Implicit declarations are supported when there is only one filter used
on a proxy. When several filters are used, explicit declarations are mandatory.
The HTTP compression filter is one of these filters. Alone, using 'compression'
keywords is enough to use it. But when at least a second filter is used, a
filter line must be added.
@ -283,7 +283,7 @@ the structure 'stream', the field 'strm_flt' is the state of all filter
instances attached to a stream:
/*
* Structure reprensenting the "global" state of filters attached to a
* Structure representing the "global" state of filters attached to a
* stream.
*/
struct strm_flt {
@ -302,7 +302,7 @@ Filter instances attached to a stream are stored in the field
'strm_flt.filters', each instance is of type 'struct filter *':
/*
* Structure reprensenting a filter instance attached to a stream
* Structure representing a filter instance attached to a stream
*
* 2D-Array fields are used to store info per channel. The first index
* stands for the request channel, and the second one for the response
@ -659,7 +659,7 @@ For example:
The main purpose of filters is to take part in the channels analyzing. To do so,
there is 2 callbacks, 'flt_ops.channel_pre_analyze' and
'flt_ops.channel_post_analyze', called respectively before and after each
analyzer attached to a channel, execpt analyzers responsible for the data
analyzer attached to a channel, except analyzers responsible for the data
parsing/forwarding (TCP or HTTP data). Concretely, on the request channel, these
callbacks could be called before following analyzers: