Serial typo

man/hpack_decode.3.rst

@@ -195,7 +195,7 @@ a header list, it becomes a lot simpler::
 
 This last state machine describes the events where ordering is key. If you
 follow arrows in the detailed state machines, you will find that a ``NEVER``
-event may be followed by an ``INSERT`` event. That is never the case, but in
+event may be followed by an ``INDEX`` event. That is never the case, but in
 order to keep the detailed state machines *simpler* this detail is omitted.
 
 RETURN VALUE

man/hpack_encode.3.rst

@@ -137,7 +137,7 @@ events. For instance a NAME event belongs after a FIELD event::
                +--<---- DATA -'
                |         |
                |         v
-    (end) <----+--<--- INSERT
+    (end) <----+--<--- INDEX
 
 If you are familiar with regular expressions, here is a translation of the
 encoding state machine to a regular expressions using the initials of the
@@ -172,7 +172,7 @@ many times and ``BAZ`` events can happen one to many times::
                 |        DATA+
                 |          |
                 |          v
-    (end) <-----+------ INSERT?
+    (end) <-----+------- INDEX?
 
 But the role of the dynamic table events is not directly related to the HTTP
 message that is being decoded. If you focus on the events that help you build

man/hpack_foreach.3.rst

@@ -59,7 +59,7 @@ event-driven HPACK codec written in C. Both HPACK decoders and encoders share
 a dynamic table in sync, it is possible outside of block processing to probe
 the contents of the dynamic table. However, the dynamic table entries are not
 persistent and MUST be considered stale after the decoding or encoding of an
-HPACK block if ``EVICT`` or ``INSERT`` events occurred.
+HPACK block if ``EVICT`` or ``INDEX`` events occurred.
 
 The ``hpack_static()`` and ``hpack_dynamic()`` functions walk respectively the
 static table and the dynamic table of *hpack* and calls *cb* for all entries