Open u5surf opened 2 years ago
Reading through the docs at https://tools.ietf.org/html/rfc7234#section-5.2.2.4 / https://www.rfc-editor.org/rfc/rfc7230#section-5.7.2 / https://www.rfc-editor.org/rfc/rfc7230#section-4 - which seem a bit more clear, it seems you may be correct.
This check was originally taken from expressjs/compression
, specifically, these lines: https://github.com/expressjs/compression/blob/ad5113b98cafe1382a0ece30bb4673707ac59ce7/index.js#L270-L277
The issue that added it there made a not-unreasonable case for it: https://github.com/expressjs/compression/issues/51
However, I think we can do better in Rust / Tide. For that kind of use-case we could export a special type and detect that on the request extensions, like a struct NoCompress;
.
https://github.com/Fishrock123/tide-compress/blob/845698b90b60d12d09f3db742962a3990310e318/src/middleware.rs#L125-L134
I consider that we don't have to care any Cache-Control: no-transform to compress any contents.
For example, Nginx gzip filter doesn't care this headers, also the ngx_brotli module does. https://github.com/nginx/nginx/blob/master/src/http/modules/ngx_http_gzip_filter_module.c#L220 https://github.com/google/ngx_brotli/blob/master/filter/ngx_http_brotli_filter_module.c
Why these Nginx module don't care this point? Because, the rfc 9110 says that
Cache-Control: no-transform
does not apply to message transformations that do not change the content, such as the addition or removal of transfer codings. Thus I consider that the compression features indicates a such message transformations(addition Transfer-Encoding: gzip etc...), it should be available these features.https://www.rfc-editor.org/rfc/rfc9110.html
If you agree this approach, I would like to work on this issue. Just removing the procedure to confirm the Cache-Control: no-transform.