{"action":"opened","issue":{"url":"https://api.github.com/repos/http2/http2-spec/issues/767","repository_url":"https://api.github.com/repos/http2/http2-spec","labels_url":"https://api.github.com/repos/http2/http2-spec/issues/767/labels{/name}","comments_url":"https://api.github.com/repos/http2/http2-spec/issues/767/comments","events_url":"https://api.github.com/repos/http2/http2-spec/issues/767/events","html_url":"https://github.com/http2/http2-spec/issues/767","id":369865041,"node_id":"MDU6SXNzdWUzNjk4NjUwNDE=","number":767,"title":"HPACK Dynamic Table Size and Lazy Huffman Decoding","user":{"login":"samoconnor","id":8266283,"node_id":"MDQ6VXNlcjgyNjYyODM=","avatar_url":"https://avatars2.githubusercontent.com/u/8266283?v=4","gravatar_id":"","url":"https://api.github.com/users/samoconnor","html_url":"https://github.com/samoconnor","followers_url":"https://api.github.com/users/samoconnor/followers","following_url":"https://api.github.com/users/samoconnor/following{/other_user}","gists_url":"https://api.github.com/users/samoconnor/gists{/gist_id}","starred_url":"https://api.github.com/users/samoconnor/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/samoconnor/subscriptions","organizations_url":"https://api.github.com/users/samoconnor/orgs","repos_url":"https://api.github.com/users/samoconnor/repos","events_url":"https://api.github.com/users/samoconnor/events{/privacy}","received_events_url":"https://api.github.com/users/samoconnor/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2018-10-14T03:55:06Z","updated_at":"2018-10-14T03:55:06Z","closed_at":null,"author_association":"NONE","body":"The [FAQ says](https://http2.github.io/faq/#why-is-there-an-eos-symbol-in-hpack) that because of the padding in HPACK’s huffman encoding...\r\n> many headers can be interpreted without being Huffman decoded\r\n\r\nFollowing this logic we have implemented a lazy HPACK decoder that defers Huffman decoding until a string needs to be interpreted or compared to a non-ecoded string. In the case of comparison we only decode as many bytes as needed to find the first mismatch.\r\n\r\nHowever, it seems that we will have to huffman decode most strings anyway in order to follow the spec with regard to calculate dynamic table size.\r\n\r\n[RFC7541 4.1](https://httpwg.org/specs/rfc7541.html#rfc.section.4.1) says that headers have to be huffman decoded in order to calculate the dynamic table size:\r\n> The size of an entry is calculated using the length of its name and value without any Huffman encoding applied.\r\n\r\nIt is inefficient to have to compute a fictional \"table size\" using the decoded size +32, when our actual  Huffman encoded table size is smaller.\r\n\r\n[RFC7541 4.4](https://httpwg.org/specs/rfc7541.html#rfc.section.4.4) says that entries \"are\" evicted in certain circumstances. Note that it does not say \"MUST be\" or \"SHOULD be\":\r\n\r\n> Before a new entry is added to the dynamic table, entries **are** evicted from the end of the dynamic table until the size of the dynamic table is less than or equal to (maximum size - new entry size) or until the table is empty.\r\n\r\nMaybe this should be relaxed to say \"SHOULD be evicted\" to allow lazy implementations that might prefer to defer eviction to a later time, or use a more relaxed threshold. For example, an implementation that ueses the huffman encoded size to compute table size will never prematurely evict entries that the encoder would later rely on. Instead it will harmlessly retain some entries that the encoder would assume had been evicted.\r\n\r\nIs there any reason that a decoder MUST not leave entries in the dynamic table after the strict interpretation of the table size calculation would have evicted them?\r\n\r\nIt seems that the only way an encoder could know that a decoder was being lazy and not evicting entries is by sending a deliberately out of bounds index and checking for a decoding error."}}
{"actor":{"display_login":"samoconnor"}}