HTTP2 (HPACK) Как получить индекс таблицы динамической декомпрессии из полезной нагрузки

Question

"Сообщение запроса 1" использует индекс 31 статической таблицы для отправки информации о типе содержимого. Затем запись добавляется в динамическую таблицу со значением индекса 63. Как получить значение индекса динамической таблицы из "Сообщение запроса 1"?

Сообщение-запрос 1:

Header: content-type: multipart/related; boundary=++Boundary
    Name Length: 12
    Name: content-type
    Value Length: 38
    Value: multipart/related; boundary=++Boundary
    content-type: multipart/related; boundary=++Boundary
    [Unescaped: multipart/related; boundary=++Boundary]
    Representation: Literal Header Field with Incremental Indexing - Indexed Name
    Index: 31
Hex dump
  5f 9d a6 da 12 6a c7 62 58 b0 b4 0d 25 93 ed 48
  cf 6d 52 0e cf 50 7f bf f7 74 f6 d5 20 ec f5

Сообщение-запрос 2:

Header: content-type: multipart/related; boundary=++Boundary
    Name Length: 12
    Name: content-type
    Value Length: 38
    Value: multipart/related; boundary=++Boundary
    content-type: multipart/related; boundary=++Boundary
    [Unescaped: multipart/related; boundary=++Boundary]
    Representation: Indexed Header Field
    Index: 63
Hex dump : 0xbf (dynamic table index value)

Answer 1

Если я вас правильно понял: ваш первый запрос помечен как "Поле с инкрементным индексированием". Это означает, что этот заголовок также имел этот индекс в статической или динамической таблице, и он должен быть добавлен в динамическую таблицу (потому что он имеет другое значение). Первый индекс динамической таблицы - 62. Это потому, что статическая таблица заканчивается на 61. Когда заголовок добавляется в динамическую таблицу, он попадает на вершину - индекс 62 (RFC7541-2.3). Я предполагаю, что вы не показали нам весь запрос, скорее всего, у него был другой инкрементный заголовок, который занимал позицию выше этого.

Answer 2

МэдБард прав. Шестнадцатеричный дамп заголовка показывает, что первый октет 5f = 01011111.

Согласно RFC 7541 «6.2.1. Буквенное поле заголовка с добавочной индексацией», первые два бита — 01 — указывают, что поле заголовка является новым и должно быть добавлено к динамической таблице. Поскольку следующие 6 бит (011111) не все равны 0, они ссылаются на имя заголовка в статической таблице. 011111 — это индекс имени заголовка, который будет использоваться в новом поле заголовка. 011111 равно 31, поэтому он берет имя заголовка в индексе 31 статической таблицы, который является «типом контента» (см. «Приложение A. Определение статической таблицы» RFC 7541). Таким образом, значение поля заголовка состоит из имени статической таблицы (тип содержимого) и значения, которое передается по сети в Запросе 1. (Значение также кодируется Хаффманом для экономии нескольких байтов, что почему мы не можем прочитать ASCII напрямую из шестнадцатеричного дампа). Затем этот новый заголовок добавляется к индексу 62 таблицы поиска. Индексы всех предыдущих записей в динамической части таблицы поиска увеличиваются на единицу (например, предыдущие 62 становятся 63, поскольку это очередь FIFO).

Другой заголовок был добавлен в динамическую часть таблицы поиска после интересующего, поскольку мы видим, что индекс поиска в запросе 2 равен 63, а не 62, и, таким образом, с момента добавления он был увеличен на 1. Если бы вы продолжали отслеживать добавление новых заголовков, вы бы увидели, что индекс этого конкретного заголовка будет продолжать увеличиваться. В конце концов, он будет исключен из таблицы поиска, когда размер динамической таблицы будет исчерпан.