Don't compress on server sent events

[Kludex]

• Alternative to flush() after writing to gzip_file #2753

cc @vin

[vin]

Some things that still appear a little off to me:

1. we do write without flush followed by an immediate read, so the read value may (and often is) empty. Since this is intentional, I think it deserves a code comment and arguably a different behavior: does it make sense to await self.send(message) when the message body is empty?
2. The documentation currently states The middleware will handle both standard and streaming responses. - I think this deserves to include some more detail about when it will be disabled, and when streaming responses may be buffered resulting in potential delays.

[Kludex]

The documentation currently states The middleware will handle both standard and streaming responses. - I think this deserves to include some more detail about when it will be disabled, and when streaming responses may be buffered resulting in potential delays.

We can add more information to the docs, yep.

we do write without flush followed by an immediate read, so the read value may (and often is) empty. Since this is intentional, I think it deserves a code comment and arguably a different behavior: does it make sense to await self.send(message) when the message body is empty?

I haven't consider the option of not sending empty messages. From the client point of view, nothing changes, since the server will not send anything anyway... If you have a middleware, it may help to know this.

---

As a first step, I think we need to add more details to the docs. Not much, just point out what happens on streaming.

[Kludex]

It seems there are more content types that can be excluded, according to Ameobea/rocket_async_compression@64a984d

[Kludex]

Happy to add more content-types on the constant if asked for.

[michi42]

Would it be possible to make the behavior configurable (excluded types, and whether to flush after each chunk for streaming responses) as parameters when creating the middleware?

The behavior proposed in #2753 makes a lot of sense if you expect relatively large SSE messages - we have e.g. an use case where we stream data for live charts over SSE, updates can reach 10-100 KB in size, which would profit significantly from compression.