1992092 - Overthinkink the old bug/feature 1080174 and maybe undo it?

Status: RESOLVED WONTFIX

(Core :: Layout: Text and Fonts, defect)

Description

[Sebastian Pinzer]

Hello,

we had the issue with our own projects, that we send out Woff files with gzip compression. The only browser which did not allowed this is the firefox.

So we researched the problem and find out that firefox forbid the gzip compression because of te feature/bug ticket 1080174 from 11 years ago.

We tested the difference between compressed and orginal Woff files and find out that, in our case, the compression is about 50%. Do the argument in this old bug ticket is not really working today.

Maybe you can reethinking this and allow the gzip compression for woff and woff2 files.

As i mentioned, the firefox Browser is the only Browser we found, which do not allow this.

thanks

Comment 1

[Jonathan Kew [:jfkthame]]

It's a bit surprising to me that you'd see anywhere near 50% compression of woff or woff2 files. Could you share one or two examples of the woff/woff2 files you're using where gzip gives such significant further compression? (Or is it possible that whatever toolchain is creating your woff files is not actually applying internal compression to them?)

Comment 2

[Sebastian Pinzer]

Ok, i checked it and it look's like my collegue gave me incorrect informations.

The compression in my tests are not really great. Sorry for that, i should have tested it by myself, before posting.

But never the less, all other browsers we tested, accept the files also compressed.
Yes it makes no sence to compress it twice, but in our case we have all files from our webApp already comressed and have the problem to uncompress the woff files in case of an firefox browser.

But no worry, if you want you can close this ticket.
I don't know which is the right way. I think both ways would work. But in the end the server decides if it compress the files or not.

thanks and best regards

Comment 3

[Emilio Cobos Álvarez [:emilio]]

Jonathan should we WONTFIX? Or track changing it perhaps?

Comment 4

[Jonathan Kew [:jfkthame]]

I think I'd lean towards WONTFIX, because applying gzip to these already internally-compressed formats just creates extra work for both server (either during site creation, if the gzipped resources are stored statically, or dynamically if they're compressed on the fly) and client compared to serving the woff or woff2 file as-is, while providing minimal if any bandwidth savings.

It looks like our font-resource requests explicitly include the http header Accept-Encoding: identity, so if a server nevertheless responds with a gzip-encoded resource, it is misconfigured.