Code change:
3. <del> When a compression dictionary is available for use for a given request, the algorithm to be used is negotiated through the regular mechanism for negotiating content encoding in HTTP. </del> <ins> The "br-d" content encoding identifies a resource that is a "Dictionary-Compressed Brotli" stream. </ins> <del> The dictionary to use is negotiated separately and advertised in the "Available-Dictionary" request header. </del> <ins> A "Dictionary-Compressed Brotli" stream is a Brotli RFC7932 stream for a response that has been compressed with an external dictionary using a compression window not larger than 16 MB. Clients that announce support for br-d content encoding MUST be able to decompress resources that were compressed with a window size of up to 16 MB. With Brotli compression, the full dictionary is available during compression and decompression independent of the compression window, allowing for delta-compression of resources larger than the compression window. </ins> <del> 3.1. </del> <ins> 4. The "zstd-d" content encoding identifies a resource that is a "Dictionary-Compressed Zstandard" stream. </ins> <del> This document introduces two new content encoding algorithms: </del> <ins> A "Dictionary-Compressed Zstandard" stream is a Zstandard RFC8878 stream for a response that has been compressed with an external dictionary. </ins> <del> br-d: Brotli RFC7932 using an external compression dictionary and a compression window of not more than 16 MB. </del> <ins> Clients that announce support for zstd-d content encoding MUST be able to decompress resources that were compressed with a window size of at least 8 MB or 1.25 times the size of the dictionary, which ever is greater, up to a maximum of 128 MB. </ins> <del> zstd-d: Zstandard RFC8878 using an external compression dictionary and a compression window of not more than 8 MB. </del> <ins> The window size used will be encoded in the content (currently, this can be expressed in powers of two only) and it MUST be lower than this limit.  An implementation MAY treat a window size that exceeds the limit as a decoding error. </ins> <del> 3.2. </del> <ins> With Zstandard compression, the full dictionary is available during compression and decompression until the size of the input exceeds the compression window.  Beyond that point the dictionary becomes unavailable.  Using a compression window that is 1.25 times the size of the dictionary allows for full delta compression of resources that have grown by 25% between releases while still giving the client control over the memory it will need to allocate for a given response. </ins> <del> The client adds the algorithms that it supports to the "Accept- Encoding" request header. e.g.: </del> <ins> 5. </ins> <del> 3.3. </del> <ins> When a compression dictionary is available for use for a given request, the encoding to be used is negotiated through the regular mechanism for negotiating content encoding in HTTP through the "Accept-Encoding" request header and "Content-Encoding" response header. The dictionary to use is negotiated separately and advertised in the "Available-Dictionary" request header and "Content-Dictionary" response header. </ins> <del> If a server supports one of the dictionary algorithms advertised by </del> <ins> 5.1. The client adds the content encodings that it supports to the "Accept-Encoding" request header. e.g.: 5.2. If a server supports one of the dictionary encodings advertised by </ins> the client and chooses to compress the content of the response using the dictionary that the client has advertised then it sets the "Content-Encoding" response header to the appropriate value for the

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.