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: And as a general approximation, one wants this dictionary during the entire reconstruction process, so the window size is effectively the size of the content to rebuild. Zstandard has a "windowless" mode which states exactly that : the size of the "window" is the size of the content. For this to work, one has to set the size of the content at the beginning of the compression process . Setting the content size is either an automatic operation when data is provided entirely upfront (), or, when data is provided in small increments (), it must be stated explicitly at the beginning (). will automatically trigger the "windowless" mode when the declared content size is smaller than the set Window size (effectively reducing the memory requirement for the decoder side). I'm not sure if there is another way to trigger it. Note that the decoder will be informed of the Window Size requirement by reading the frame header, and may decide to not proceed if this value is deemed too large. For example, has a default 128 MB limit, and will refuse to decompress payload requiring more that that, unless explicitly authorized to employ more memory (). Just for reference, offers a "large delta compression" mode with the command . It has made us somewhat familiar with some of these issues. In situations where the amount of data to compress and compare is very large, we now prefer to both the dictionary content and the destination file. It has proven useful to reduce memory pressure.
Thanks. That makes things a bit more complicated for the case where we want to require a minimum window size that the server can trust that all clients advertising content-encoding will be able to decode. For the dictionary case it might be cleanest to use the same 128MB limit for window sizes as the default zstd limit (knowing that the client won't allocate that much unless it actually gets a stream that uses it).
Hello. Shared dictionary is placed in the address space between backward reference window and static dictionary. In other words it does not interfere with normal compression window, but using it makes "static dictionary" references more expensive. We decided to order it that way, because shared dictionary works almost the same way as extra window. Sorry for the late response. Best regards, Eugene.
Extra note. As you can see brotli allows backward distances behind window.