Code change:
Name: zstd-d <del> Description: A stream of bytes compressed using the Zstandard protocol with an external dictionary of not more than 8 MB. </del> <ins> Description: "Dictionary-Compressed Zstandard" data format. </ins> Reference: This document Notes: <del> 4.2. </del> <ins> 6.2. </ins> IANA is asked to update the "Hypertext Transfer Protocol (HTTP) Field Name Registry" registry (HTTP) according to the table below: <del> 5. </del> <ins> 7. </ins> To minimize the risk of middle-boxes incorrectly processing dictionary-compressed responses, compression dictionary transport MUST only be used in secure contexts (HTTPS). <del> 6. </del> <ins> 8. </ins> The security considerations for Brotli RFC7932 and Zstandard RFC8878 apply to the dictionary-based versions of the respective algorithms. <del> 6.1. </del> <ins> 8.1. </ins> The dictionary must be treated with the same security precautions as the content, because a change to the dictionary can result in a

Related discussion:
text: Let's then assume it implies a window size limit of 50 MB (dictionary size) and the compressor is not informed of the size of the payload. In which case, the compressor will have to set a Window Size, and it will have to settle for the largest representable window size under the limit, which happens to be 48 MB. Therefore, the dictionary won't be used during the compression of the last 2 MB of the payload. With the proposed +25% tolerance rule, the limit would become 62.5 MB, and the largest representable window size under the limit is 60 MB. Now the dictionary remains active during the entire compression of the 50 MB payload. When the data to decompress ends up being smaller than the window size, it's obviously not a problem for the decompression process: the final decompressed size is still properly reported at the end. It's just that the intermediate buffer allocation will be larger than it could have been. Note that uses for the allocation of buffers, so the address space is just reserved, but the physical memory may never be used if it's not needed (i.e. if there is no write action on the later segment part). +25% is more like a suggestion, this can certainly be discussed if some other limit feels better. I liked that it's a (binary) clean factor, and it's larger than , which covers the scenario above, and gives a little bit of breathing room if the newer payload is a bit larger than the older reference one. I see this scenario as being very distinct from delta-compression. For delta-compression, we expect large segments to be identical between the reference and the payload to compress, so we want this ability to access the reference during the entire compression of the payload. The price to pay is that the reference is very specific, and is not designed to offer any serious benefit to any other payload. Custom dictionaries are different: they are supposed to carry the most relevant "commonalities" detected across a set of samples. Presuming a large enough sample set, the common components are not expected to be very large. In such a scenario, the custom dictionary is expected to be (relatively) lightweight (compared to delta-compression), likely in the <= 100 KB range.