-
Notifications
You must be signed in to change notification settings - Fork 36
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
Expand documentation #117
Comments
PR welcome! |
The user/client is the one that ultimately determines what compression methods it accepts. |
It is just an example. If you don't do anything, clients supporting
If a client or a server doesn't support an encoding from the list, the next one will be checked and used. Does this explanation work for you? If not, ask away and let's refine our message. If it does, I'll be happy to submit a PR to update the docs. |
@uhop Thank you, yes I think your answers make sense. It'd be helpful as well to be clear about what will happen by default (whether Node 11.7+ or an unsupported version), and then the order the fallbacks will happen. So, here's my understanding based on what you've said:
will result in responses using brotli compression if using Node 11.7+, and otherwise return gzip responses. If for some reason gzip doesn't work or is not an option (again, I don't know anything about compression), then deflate is used. This is always the order of selection. If an Options object is passed, the order of its keys doesn't change this order. Is that correct? Also, for
does this mean that in all cases, Koa Compress checks the request's Accept-Encoding header to further eliminate compression options from the selection? It seems natural that this would be the case, but I'm not one for assumptions..
|
Encoders are going to be tried in this order:
When a client sends
In the former case, In the latter case, it will be What if all encoders are somehow eliminated? The catch-all will be
|
Why is 'br' not listed here also? |
Beats me. TBH using IMHO the only plausible scenario for |
I think you've cleared up everything that was missing from the docs, thank you! I don't understand the relation between our last two comments, but
tells me you didn't leave out the |
I guess that the authors decided to be reasonably conservative and in the case of |
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Encoding we are just trying to be as true to the specs as possible :) it's very confusing |
Hello there! Catching up with this thread. Have a question for a simple general use case using Koa for an API for a website. Can just use In examples around the internet, I've seen Thanks to all for contributing and maintaining |
Here's what we do for @forwardemail and @ladjs: // https://github.com/koajs/compress
app.use(compress({
br: {
params: {
[zlib.constants.BROTLI_PARAM_MODE]: zlib.constants.BROTLI_MODE_TEXT,
[zlib.constants.BROTLI_PARAM_QUALITY]: 4
}
}
})); |
This middleware looks useful, but I'm not sure how to use it. Perhaps more examples with explanations would help?
I'd like to use brotli if the client accepts it, and fallback to gzip if not. In the readme, your example disables brotli and later states,
Is brotli disabled because Node includes it natively or because that's just the example?
Does the order of the encodings in the options object matter or is the "preference" always the same order?
Does one encoding fallback to another if not supported?
I'm unable to help with contributing these changes because I don't understand how it works, but I think answering these questions in the readme would help others understand. Or maybe it's just me..
The text was updated successfully, but these errors were encountered: