0

“请求消息 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)
4

2 回答 2

0

MadBard 是对的。标头的十六进制转储显示第一个八位字节是 5f = 01011111。

根据 RFC 7541 “6.2.1. Literal Header Field with Incremental Indexing”，前两位 - 01 - 表示标题字段是应该附加到动态表的新字段。由于接下来的 6 位 (011111) 并非全为 0，因此它们引用了静态表中的标头名称。011111 是要在新标题字段中使用的标题名称的索引。011111 是 31，因此它采用静态表索引 31 处的标题名称，即“content-type”（参见 RFC 7541 的“附录 A. 静态表定义”）。因此，标头字段的值由静态表名称（内容类型）和请求 1 中通过网络传输的值组成。（该值也经过 Huffman 编码以节省几个字节，即为什么我们不能直接从十六进制转储中读取 ASCII）。然后将这个新标题附加到查找表的索引 62。查找表的动态部分中所有先前条目的索引都加一（例如，先前的 62 变为 63，因为它是一个 FIFO 队列）。

另一个标头被添加到查找表的动态部分之后，因为我们可以看到请求 2 中的查找索引是 63，而不是 62，因此自添加以来它被提高了 1。如果您在添加更多标头时继续监控，您会看到此特定标头的索引将不断增加。最终，当动态表大小用尽时，它将从查找表中逐出。

于 2020-12-16T16:04:54.270 回答
0

如果我理解正确：您的第一个请求标记为“具有增量索引的字段”。这意味着此标头在静态或动态表中也有此索引，并且必须将其添加到动态表中（因为它具有其他值）。动态表的第一个索引是 62。这是因为静态表以 61 结束。当标题添加到动态表时，他会到达前 62 索引（RFC7541-2.3）。我假设您没有向我们展示整个请求，很可能它有另一个增量标头，它占据了高于此的位置。

于 2020-07-27T01:41:34.093 回答