DOC: Fix typos in different subsections of the documentation

Fix typos found in the design-thoughts, internals and lua-api
subsections of the documentation.
diff --git a/doc/internals/body-parsing.txt b/doc/internals/body-parsing.txt
index 45d7034..be209af 100644
--- a/doc/internals/body-parsing.txt
+++ b/doc/internals/body-parsing.txt
@@ -81,7 +81,7 @@
 
 msg.sol  : start of line. Points to the beginning of the current header line
            while parsing headers. It is cleared to zero in the BODY state,
-           and contains exactly the number of bytes comprising the preceeding
+           and contains exactly the number of bytes comprising the preceding
            chunk size in the DATA state (which can be zero), so that the sum of
            msg.sov + msg.sol always points to the beginning of data for all
            states starting with DATA. For chunked encoded messages, this sum
@@ -91,7 +91,7 @@
            TRAILERS state, it contains the length of the last parsed part of
            the trailer headers.
 
-msg.eoh  : end of headers. Points to the CRLF (or LF) preceeding the body and
+msg.eoh  : end of headers. Points to the CRLF (or LF) preceding the body and
            marking the end of headers. It is where new headers are appended.
            This offset is automatically adjusted when inserting/removing some
            headers. It always contains the size of the headers excluding the
diff --git a/doc/internals/connection-header.txt b/doc/internals/connection-header.txt
index 99e4549..b74cea0 100644
--- a/doc/internals/connection-header.txt
+++ b/doc/internals/connection-header.txt
@@ -180,7 +180,7 @@
     on versions and current connection header(s).
 
   - both CLO and TUN modes work similarly, they need to set a close mode on the
-    reponse. A 1.1 response will exclusively need the close header, while a 1.0
+    response. A 1.1 response will exclusively need the close header, while a 1.0
     response will have it removed. Any keep-alive header is always removed when
     found.
 
diff --git a/doc/internals/entities-v2.txt b/doc/internals/entities-v2.txt
index 94f5655..38d633d 100644
--- a/doc/internals/entities-v2.txt
+++ b/doc/internals/entities-v2.txt
@@ -58,7 +58,7 @@
   - if a data-layer accept() has been performed
     => possibly 2 bits, to indicate the need to free()
 
-On the connect() side, we need to konw :
+On the connect() side, we need to know :
   - the desire to send a header (eg: send-proxy)
   - if this header has been sent
     => maybe both info might be combined
diff --git a/doc/internals/entities.txt b/doc/internals/entities.txt
index 646f9ea..d384395 100644
--- a/doc/internals/entities.txt
+++ b/doc/internals/entities.txt
@@ -68,7 +68,7 @@
 Connector
 ---------
 
-A connector is the entity which permits to instanciate a connection to a known
+A connector is the entity which permits to instantiate a connection to a known
 destination. It presents a connect() callback, and as such appears on the right
 side of diagrams.
 
diff --git a/doc/internals/filters.txt b/doc/internals/filters.txt
index ce054df..61a0155 100644
--- a/doc/internals/filters.txt
+++ b/doc/internals/filters.txt
@@ -293,8 +293,8 @@
                                              * If NULL, we start from the first filter.
                                              * 0: request channel, 1: response channel */
         unsigned short flags;               /* STRM_FL_* */
-        unsigned char  nb_req_data_filters; /* Number of data filters registerd on the request channel */
-        unsigned char  nb_rsp_data_filters; /* Number of data filters registerd on the response channel */
+        unsigned char  nb_req_data_filters; /* Number of data filters registered on the request channel */
+        unsigned char  nb_rsp_data_filters; /* Number of data filters registered on the response channel */
     };
 
 
@@ -544,7 +544,7 @@
 3.4. HANDLING THE STREAMS ACTIVITY
 -----------------------------------
 
-You may be interessted to handle streams activity. For now, there is three
+You may be interested to handle streams activity. For now, there is three
 callbacks that you should define to do so:
 
   * 'flt_ops.stream_start': It is called when a stream is started. This callback
diff --git a/doc/internals/notes-layers.txt b/doc/internals/notes-layers.txt
index 8b3d040..7ca51fe 100644
--- a/doc/internals/notes-layers.txt
+++ b/doc/internals/notes-layers.txt
@@ -9,7 +9,7 @@
     available via conn_streams, sends data to the network
 
 
-The connection zone contains multiple layers which behave independantly in each
+The connection zone contains multiple layers which behave independently in each
 direction. The Rx direction is activated upon callbacks from the lower layers.
 The Tx direction is activated recursively from the upper layers. Between every
 two layers there may be a buffer, in each direction. When a buffer is full
@@ -82,7 +82,7 @@
     requested size, thus no need to re-enable receiving on the lower layers.
 
   - RECV_ONE_SHOT : perform a single read without re-enabling reading on the
-    lower layers, like we currently do when receving an HTTP/1 request. Like
+    lower layers, like we currently do when receiving an HTTP/1 request. Like
     RECV_ENOUGH where any size is enough. Probably that the two could be merged
     (eg: by having a MIN argument like RECV_MIN).
 
@@ -99,7 +99,7 @@
 
 
 Both operations should return a composite status :
-  - number of bytes transfered
+  - number of bytes transferred
   - status flags (shutr, shutw, reset, empty, full, ...)