- From: Jesse Wilson <jesse@swank.ca>
- Date: Mon, 26 Aug 2013 10:44:20 -0400
- To: ietf-http-wg@w3.org
- Message-ID: <CAME=j1m4Lc8d5MAX2Ax_6h2P8zYK72RMZuVRhdT3VLR9mNDSAg@mail.gmail.com>
I'm attempting to implement HTTP/2.0 for OkHttp<http://square.github.io/okhttp/>, Square's HTTP client for Android and Java. I'd like to clarify how header table pruning works with replacement-by-index. The doc says<http://http2.github.io/compression-spec/compression-spec.html#rfc.section.3.2.3> : When the modification of the header table is the replacement of an existing entry, the replaced entry is the one indicated in the literal representation before any entry is removed from the header table. *If the entry to be replaced is removed* from the header table when performing the size adjustment, the replacement entry is inserted at the beginning of the header table. Is the entry to be replaced removed before pruning-from-0 begins? Or does all pruning happen, and then the replacement happens? Here‘s an example situation where the order of these operations is relevant. Suppose I’ve got a headers table containing 4 entries, each 1024 bytes. The max size of this table is 4096. 0 A: <value> (entry size: 1024) 1 B: <value> (entry size: 1024) 2 C: <value> (entry size: 1024) 3 D: <value> (entry size: 1024) At this point I receive a literal header with substitution indexing “E” at index 2 and entry size 2048. This will replace C. If I prune first, I remove A and B. Substituting yields this new headers table: 0 E: <value> (entry size: 2048) 1 D: <value> (entry size: 1024) If I remove the replaced entry C first, I get a different result: 0 B: <value> (entry size: 1024) 1 E: <value> (entry size: 2048) 2 D: <value> (entry size: 1024) Another way to look at it is whether I'm pruning until currentSize + size(E) <= max or until currentSize - size(C) + size(E) <= max. Thanks!
Received on Monday, 26 August 2013 14:45:20 UTC