mark application/octet-stream as compressible

[greggman]

didn't see anything in iana rfc about this not being compressible.

I see a few extensions that are probably already compressed like distz and dmg but overall most things sent as application/octet-stream would benefit from compression it seems.

[dougwilson]

most things sent as application/octet-stream would benefit from compression it

It's possible. Can you provide data on this? Perhaps a definition of "most" like what % of data transferred under this is compressible and by how much? Or at least something concrete to make the decision on?

[vchirikov]

Hi @dougwilson .
I ran into this issue because I'am using Blazor (wasm, dll extension) on gh-pages and it uses this library.
So here information about gz / br / uncompressed for Blazor

Filename(without extension)	Original size (.dll)	gzip (.gz)	brotli (.br)
Blog	77824	34191	29487
BrowserInterop	149504	54428	41707
Markdig	401408	153788	123906
Microsoft.AspNetCore.Components	110592	48191	41705
Microsoft.AspNetCore.Components.Web	19968	8322	6520
Microsoft.AspNetCore.Components.WebAssembly	43520	20586	17876
Microsoft.Bcl.AsyncInterfaces	5120	1957	1695
Microsoft.Extensions.Configuration.Abstractions	10752	4475	3916
Microsoft.Extensions.Configuration	12288	5776	4998
Microsoft.Extensions.Configuration.Json	10240	4790	4150
Microsoft.Extensions.DependencyInjection.Abstractions	20992	7863	6686
Microsoft.Extensions.DependencyInjection	62464	28253	24166
Microsoft.Extensions.Logging.Abstractions	37376	16362	13462
Microsoft.Extensions.Logging	19968	9466	8296
Microsoft.Extensions.Options	40960	17091	13627
Microsoft.Extensions.Primitives	25600	11258	9776
Microsoft.JSInterop	32256	14463	12960
Microsoft.JSInterop.WebAssembly	6656	2972	2603
mscorlib	1808896	693895	577881
SharpYaml	217088	88250	75471
System.Core	312832	123639	104961
System	264192	114576	98052
System.Net.Http	99328	44859	38582
System.Net.Http.WebAssemblyHttpHandler	21504	9779	8533
System.Runtime.CompilerServices.Unsafe	2560	920	774
System.Text.Encodings.Web	25600	9155	8085
System.Text.Json	217088	85301	71869
Toolbelt.Blazor.HeadElement.Abstractions	8192	3304	2863
Toolbelt.Blazor.HeadElement	9728	4142	3565
Toolbelt.Blazor.HeadElement.Services	23040	9026	7623
WebAssembly.Bindings	19456	9134	8058

[wesleytodd]

I did a cursory search for this and I also see no evidence this is not compressible. That said, I am not confident enough to approve and merge this change without more input than we have here. If anyone can help make a strong case for this change I will try to land it, but else wise I will let this sit for now.

[bjohansebas]

I really can't find any information that this should be compressible. :c

[greggman]

compression is supposed to be transparent. You'd need some evidence that it's NOT compressible, otherwise, by default, everything is compressible.

[bjohansebas]

I don't completely agree with that. If this is made compressible, then higher-level packages like compression would compress the responses when it has that MIME type. There wouldn't be a problem if it can actually be compressed, but it would be a big issue where it shouldn't be done.

[wesleytodd]

Yeah, it is a bit of a tough case. I think I theory @greggman should be correct, but in reality if @bjohansebas is correct it is a much worse outcome because it actually breaks things. I don't have a good answer, but in theory we do not consider data changes like this as part of our semver contract so releasing here would be reasonable. The problem is that when we went to update in compression, if that started breaking users we would need to either pin back there, or revert here. Which would be rather disruptive. Especially considering that folks who really wanted compression here could have already done it on their own I think.

[bjohansebas]

I want to trust that I won't break compression.

Fastify seems to accept this MIME type for compression.

https://github.com/fastify/fastify-compress/blob/da5235efc1b1c672493f94fe9d8f675d3269c2a5/index.js#L111

I would even like to ping the maintainers of that package to get their opinion, since it could also break them.

edit: I've posted on Slack to see if anyone from Fastify can take a look at it

[mcollina]

Ok for us

[wesleytodd]

Ah, good find on that @bjohansebas and for pinging in @mcollina for the confirmation. Sounds like we agree then that we can merge this for the next release.