Detect when compression middleware is installed?

[rexxars]

I am the author of a library called sse-channel, which implements server-sent events (SSE). For this to work in an efficient and fast manner, I need to be able to call flush on responses that pass through this compression middleware.

Currently I'm just checking for the presence of a flush method on the response and calling that, but since node has this method, it's causing me some issues. Is there a way I can detect whether the flush method is from this middleware, or if the compression middleware is applied to the response, somehow?

[dougwilson]

No, there isn't a good way to know if this module is active or not (yet?), but perhaps you may just not want your SSE responses compressed at all? If that is the case, then your code can always set the header Cache-Control: no-transform (https://github.com/expressjs/compression#compressionoptions) and this module won't even compress the response, and so doesn't require the users to setup anything special and you don't have to call .flush().

Let me know if you really do want your responses to be compressed, and I'm sure we can think of a good way to provide the indication to your code :)

[rexxars]

I'm unsure of how much impact gzip will have on SSE, since we're explicitly telling it to flush before having basically any data to work with. If gzip can somehow keep optimizing data as it comes in even though the "initial chunk" is sent, then it might actually be able to provide a pretty significant improvement. Any idea if this is the case or not?

[dougwilson]

Any idea if this is the case or not?

Yes, this is the case. Your initial chunks between .flush calls are probably not going to be very efficient (probably will be even larger than the text content itself), but if you keep the connection open long and have a lot of repetitive data, I believe the dictionary is built up between the chunks (but I would have to check).

So it sounds like the take away may be to determine if the dictionary is actually shared between the chunks or not, so it can be better evaluated if the compression is actually helping or hurting the stream (I believe it does help). In parallel, we can probably think of a good way to indicate if the response is getting compressed in a unique way that is obvious and doesn't conflict too much (darn Node.js taking res.flush() ;) ).

[rexxars]

#74 would solve this for me. Any feedback on that, @dougwilson ?

[bjohansebas]

.flush is no longer a method on HTTP OutgoingMessage, so this method is no longer needed

https://nodejs.org/api/deprecations.html#dep0001-httpoutgoingmessageprototypeflush