Code change:
request, the algorithm to be used is negotiated through the regular mechanism for negotiating content encoding in HTTP. <del> This document introduces two new content encoding algorithms: </del> The dictionary to use is negotiated separately and advertised in the "Available-Dictionary" request header. 3.1. <ins> This document introduces two new content encoding algorithms: br-d: Brotli RFC7932 using an external compression dictionary and a compression window of not more than 16 MB. zstd-d: Zstandard RFC8878 using an external compression dictionary and a compression window of not more than 8 MB. 3.2. </ins> The client adds the algorithms that it supports to the "Accept- Encoding" request header. e.g.: <del> 3.2. </del> <ins> 3.3. </ins> If a server supports one of the dictionary algorithms advertised by the client and chooses to compress the content of the response using

Related discussion:
text: 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. Consequently, by the time the payload to compress reaches 1 MB, it should already contain all references it needs to compress the rest of the file. I would not expect a large impact of the custom dictionary beyond that point, let alone beyond 8 MB. The plan would be for the library to do this adaptation automatically. The user would not have to know anything about it, though it's better if the user understands that the library selects the closest window size which is <= to the limit, so that they are not surprised if, upon inspection, the final window size is not byte-identical to the set limit. A good API documentation will likely help to reach this objective If by implementors you mean "server side programmers", they would have to know what's the implicit window size limit when a client requests a format (essentially the rule you are currently defining). Then they would set this limit as a compression parameter, and the library will take care of the adaptation into window size.
Yes. (Keeping in mind of course that most traffic in question will presumably be under the 8 MB floor and so none of this complexity will apply.) Right now the zstd library has limited controls about setting detailed window constraints. We'll need to add a new option to give users that fine-grained control. We can do that with an eye towards user simplicity.