compress/flate: Allow resetting writer with new dictionary

[nhooyr]

As of Go 1.14, compress/flate's Writer only allows resetting the write side with the same dictionary.

In contrast, the Reader can be reset with a new dictionary.

I need this to efficiently implement context takeover compression for WebSockets.

See https://tools.ietf.org/html/rfc7692#section-7.1.1

cc @klauspost

[klauspost]

What is the problem you are trying to solve? Is this a 1.14 change?

I'm not sure I understand why it is a problem to supply the dictionary when resetting?

[as]

Possibly related #18930

[nhooyr]

@klauspost

I don't want to keep a flate.Writer allocated for every connection due to memory usage. Instead, I'd rather store the rolling window myself and then grab a writer out of the pool and reset it with the window and then write a message to the connection.

[nhooyr]

I'm not sure I understand why it is a problem to supply the dictionary when resetting?

It's not a problem, that's exactly what I want to do but it's unsupported at the moment.

[klauspost]

Ah, ok, so like a Stateless compression function that accepts a dictionary or a Stateless Writer, where it keeps the history between calls, but discards everything else.

[nhooyr]

Ah my bad I forgot you already implemented that.

Is there an issue open to merge it into the stdlib or shall I keep this open?

[nhooyr]

Nvm, there is no dict option yet in your pkg.

[klauspost]

I don't have plans to submit it to the stdlib unless someone expresses a need for it. The threshold for adding stuff is of course a bit higher for the stdlib.

Adding it to the functions above would not be super easy, since everything related to history was pulled out to make it stateless. OTOH is would also not be massive. Having, say a max 8K dict would be feasible, but every call would of course require it to be re-indexed, so not free.

[klauspost]

@nhooyr You can test klauspost/compress#216

Slightly clunky API to remain backwards compatible.

[nhooyr]

Will do this weekend, thanks @klauspost

[nhooyr]

Won't be able to get to it this weekend.

Appreciate your very quick response to this issue @klauspost, I'll try to get to get to it next week.

[nhooyr]

Using this in my WebSocket library and the performance has been great.

klauspost/compress#216 (comment)

2x faster and only 100 B allocated per op for echoing a 512 random byte message with a 8 KB dictionary.