New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added support for brotli ('br') content-encoding #406
base: master
Are you sure you want to change the base?
Conversation
How are we doing? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM @danielgindi!
Thanks fo the links attached to the PR. I will love to be able to try that compression in my next project 💪
Yeah this brotli is truly amazing :) Btw we have a PR in the compression repo, to allow responses to be encoded too. It's two sides of the same coin |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I moved over one comment that was still outstanding from the first repo and a general comment to make sure our detection makes sense from the noode.js project.
@@ -16,6 +16,8 @@ before trusting. For example, `req.body.foo.toString()` may fail in multiple | |||
ways, for example the `foo` property may not be there or may not be a string, | |||
and `toString` may not be a function and instead a string or other user input. | |||
|
|||
**Note** Brotli is supported only since Node.js versions v11.7.0 and v10.16.0. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would think that the information about version support should be along with the br
support docs, otherwise users may not see it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you might be confusing the compression
repo. In this one there's no br
support section. As there's nothing to configure, it's just decoding.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still, where in the README do you want this? There's no explicit section for br
...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is the spots where you added the br
mentions that br
is one of the options.
@dougwilson Have you noticed that we suddenly have a "leak" in the older node versions in CI? |
@dougwilson Anything preventing this from being published? |
@@ -45,7 +45,7 @@ | |||
}, | |||
"scripts": { | |||
"lint": "eslint --plugin markdown --ext js,md .", | |||
"test": "mocha --require test/support/env --reporter spec --check-leaks --bail test/", | |||
"test": "mocha --require test/support/env --reporter spec --check-leaks --global __core-js_shared__ --bail test/", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We really shouldn't be adding a global leak with our changes. Is there a way to fix the leak? Just adding it to ignore is not really the best solution.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dougwilson It's from one of the libs used by either one of our existing dependencies, or mocha itself. Most probably by mocha itself.
It's a global leak introduced by json5
and by loadash
in the old versions that we are referencing. It's for deduping the code-js libs.
We are not using these in our code, so I don't think we can do anything about it - except increase dependency versions, which will break old node support.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting. Why doesn't the leak occur on master
branch or other PRs, if that is the case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even in this PR, it happened on and off. Sometimes by changing a single line with no interesting sideeffects.
I don't know if you recall but we've added and removed this before.
Also this happens only on specific very old versions of node, where that core-js dependency was required.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, strange. So that could just mean that these changes are causing it to be intermittent, not that it is intermittent without these changes. Of all the PRs and commits I push here, it has never happened, which is why it seems to point to the changes here somehow causing them to occur. It may help if maybe we approach this differently: can you just explain why it happens? For example, you say "happens only on specific very old versions of node, where that core-js dependency was required". So, which versions is that? Can we only add the exception to only those specific versions, then? You also say "except increase dependency versions". Increase which dependencies to which versions? If these are just test dependencies, we can change any of those to be whatever version is necessary for each different version of Node.js in our Travis CI file, like we are doing today.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did not deep dive that much. I only recall it was all the 0.x versions except <=0.8.
I don't really want or care to start eliminating it line by line, as those node versions are not supported for years now, and I can't do these tests without pushing little changes again and again to your CI and wait for the results. You could look at the previous CI results and see what I mean. Or maybe the whole history of CI on this branch.
What I can say for sure is that this even happened before switching between 'brotli' in process.versions
and 'createBrotliDecompress' in zlib
, and stopped with this change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dougwilson More info: the users of this corejs quirk are babel
(by requiring json5
), and eslint
.
eslint
is the immediate suspect, as the modules it requires vary depending on the source code. An syntax combination somewhere could trigger another rule to be required, and then this leak will happen as a few of the rules require lodash
which is the culprit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
** spam content removed **
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
** spam content removed **
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
** spam content removed **
0ad1d88
to
2a2f471
Compare
Is this feature stuck for some specific reason? Is there something that can be done to fix it? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
expressjs/compression#172
https://medium.com/oyotech/how-brotli-compression-gave-us-37-latency-improvement-14d41e50fee4
https://caniuse.com/#feat=brotli
(Originally #403)