HTTP2 (HPACK) How to derive dynamic decompression table index from the payload - http2

Question

"Request Message 1" is using static table index 31 to send content-type information. Then the entry is added to dynamic table with index value 63. How to derive the dynamic table index value from "Request Message 1"?
Request message 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
Request message 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

If I understand you right: Your first request marked as "Field with Incremental Indexing". That's mean that this header also had this index in static or dynamic table and it must be added to dynamic table(because it has other value). Dynamic table's first index is 62. It's because static table ends on 61. When header added to dynamic table he get to the top - 62 index (RFC7541-2.3). I will assume that you did not show us the whole request, most likely it had another incremental header, which took a position above this.

Answer 2

MadBard is right. The hex dump of the header shows the first octet is 5f = 01011111.
According to RFC 7541 "6.2.1. Literal Header Field with Incremental Indexing," the first two bits - 01 - indicate the header field is a new one that should be appended to the dynamic table. Since the next 6 bits (011111) are not all 0, they are referencing a header name in the static table. 011111 is the index of the header name to be used in the new header field. 011111 is 31, so it takes the header name at index 31 of the static table, which is "content-type" (see "Appendix A. Static Table Definition" of RFC 7541). The value for the header field is thus composed of the static table name (content-type), and the value which is carried over-the-wire in Request 1. (The value is also Huffman encoded to save a few bytes, which is why we can't read the ASCII directly from the hex dump). This new header is then appended to index 62 of the lookup table. The indices of all previous entries in the dynamic portion of the lookup table are incremented by one (e.g. the previous 62 becomes 63, since it is a FIFO queue).
Another header was added to the dynamic portion of the lookup table after the one of interest, since we can see that the lookup index in Request 2 is 63, not 62, and thus it was bumped up 1 since it was added. If you were to keep monitoring as more headers were added, you would see the index of this particular header would keep incrementing. Eventually it would get evicted from the lookup table when the dynamic table size gets exhausted.