DOC: internals: Fix spelling errors in filters.txt

diff --git a/doc/internals/filters.txt b/doc/internals/filters.txt
index cd3988fbb61d74033f7b80d3db345e78a22c1a9f..5e9b58e56194ae06d7d56b7dc89deb0e67ebb7fa 100644 (file)
--- a/doc/internals/filters.txt
+++ b/doc/internals/filters.txt
@@ -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: