-
-
Notifications
You must be signed in to change notification settings - Fork 243
Closed
Labels
Description
Is it an idea to add Brotli compression for https-requests to this module? Now support for Brotli has landed in the developer channels of Firefox and Chrome it is very likely that a significantly amount of clients will have support for this enabled in the very near future. So, it is maybe a good idea to support it in this module too.
I’m not (yet) very experienced with building modules for Node, but if there is anything I can help with, please let me know.
buzinas, marcbachmann, RemiAWE, ShimShamSam, ex1st and 124 morebuzinas, RemiAWE, Gregoor, felipecdo, antonio-muniz and 22 morerenehsz, TheAlexLichter, glemiere, jinliming2, patrickmichalina and 12 moremichalmuchakr, jonasgeiler, aykxt, Theofilos-Chamalis and khats
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
dougwilson commentedon Jan 24, 2016
Hi! This was discussed before in #59 if you want to read the prior discussion.
The answer is that we certainly can, but for it to be built-in here, we need the support either added to Node.js core or a pure-JS library.
Barring that, another option is to make this module flexible and allow for alternative user-defined encodings. There was the PR #62 but it was never completed due to a disagreement between the author and myself over a feature I wanted to be supported.
dantman commentedon Feb 1, 2016
The performance of brotli is something that should be kept in mind.
Some previous tests:
brotli isn't necessarily always more efficient than gzip. brotli's biggest advantage is that at higher compression levels, at the cost of compression time, you can get compression ratios beyond what you can do even by using zopfli.
So you don't really get an advantage from using zopfli or brotli for dynamic content. They work best when you can wait a few extra seconds to let the compressor do more work.
For most people this means making a .gz file (using zopfli) and a .bro file with brotli during your build step and using the pre-compressed files instead of dynamically compressing with either.
LeandroFavero commentedon Feb 12, 2016
dougwilson, maybe this can help:
A JavaScript port of the Brotli compression algorithm
https://github.com/devongovett/brotli.js
passcod commentedon May 25, 2016
Note that the above port of Brotli doesn't support streaming yet. People interested in brotli and zopfli in the meantime may want to have a look at https://github.com/aickin/shrink-ray.
mikemaccana commentedon Apr 4, 2017
@dantman At level 4, Brotli uses less CPU AND compresses better than gzip - here's the results of a test using the top 1000 URLs on the internet: https://blogs.akamai.com/2016/02/understanding-brotlis-potential.html
dougwilson commentedon Mar 11, 2018
It looks like Node.js is discussing adding support ad a built-in nodejs/node#18964 which should make it trivial to add to this module.
yocontra commentedon Dec 18, 2018
This library supports streaming - https://github.com/MayhemYDG/iltorb#stream (native package though, maybe make it an optional dep?)
If the maintainers are interested I can send a PR, let me know.
voxpelli commentedon Jan 7, 2019
Built in support in Node landed 2 days ago: nodejs/node#24938
6 remaining items
patrickmichalina commentedon Jun 7, 2019
I submitted a PR #156 since there was not progress on the other one.
KB1RMA commentedon Aug 7, 2019
Is there any reason Patrick's PR from above is still waiting for a merge? I'm running on 10.16 at the moment and would love to be able to turn brotli on - I can't see anything obvious holding up the release of that option via the PR.
dougwilson commentedon Aug 7, 2019
It seems like a duplicate of #150 and doesn't even address the issues that were brought up in that issue.
KB1RMA commentedon Aug 10, 2019
Ah I missed that PR, sorry. Looks like it addresses the testing well but not the options.
patrickmichalina commentedon Sep 9, 2019
I can look into the options portion as well.
nicksrandall commentedon Sep 15, 2020
Yet another PR #173
mridang commentedon Sep 3, 2024
Hi everyone. 👋🏼 It's been a god couple of years since the last comment on this thread so I'm just checking if this still slated to be done? I would hate to run off a fork. Of course, if there ways I can contribute, happy to do this. Both #172 and #173 seem to be in limbo. Thank you
Kikobeats commentedon Sep 3, 2024
I resolved this creating a standalone package: https://github.com/Kikobeats/http-compression
Working with no issues from a year.
bjohansebas commentedon Jan 8, 2025
Fixed by #194
Thanks to each person who opened PRs and those who participated in them to make this feature happen. Every discussion that took place helped make it possible to implement it.