Add Rack::Deflater middleware to production environment template #14299
Conversation
Some proxy servers, like nginx (recent versions) won't keep the ETag header if the gzip compression is enabled in the proxy-side as it would change the content. Also nginx doesn't support weak ETag yet. In some cases, serving a full application directly with Puma, for instance, may be good enough for some applications with no need for load balancing and enabling gzip compression by default in production environments is a good default to support. In other servers set-ups there may be a cluster of servers and the suggested approach in the guides of serving the assets directly from the proxy server by local assets location require them to be accessible in the same filesystem as the proxy server which may be a bit of burden in the deployment process. Another approach is to configure the proxy-server to cache those requests after the first access to the proxied url with the application serving the assets for the first access (not cached by nginx yet). But this approach doesn't work well in nginx if nginx is also responsible for gzipping the assets. Applying gzip compression directly in the backend avoid having to configure a new proxy in the path just to compress the content before it gets cached.
|
Not sure if we wanna push this type of config to everybody. I am 👎 on this... However not strongly about it. thoughts @rafaelfranca @carlosantoniodasilva |
|
Yeah, it's easy enough to add to your application if you need to, so it's better not to make it a default that might not be useful for everyone. Thanks for your contribution. |
|
I don't understand what are the drawbacks of adding such module. It won't make anything worse as far as I can tell and would still be a good default since all applications would benefit from it or in the worst case it won't make any difference... In the current state some people will have to manually research about this, while in other web frameworks and languages the default is to accept gzip requests and serve gzipped content. |
Some proxy servers, like nginx (recent versions) won't keep the ETag header if the gzip compression is enabled in the proxy-side as it would change the content. Also nginx doesn't support weak ETag yet.
In some cases, serving a full application directly with Puma, for instance, may be good enough for some applications with no need for load balancing and enabling gzip compression by default in production environments is a good default to support.
In other servers set-ups there may be a cluster of servers and the suggested approach in the guides of serving the assets directly from the proxy server by local assets location require them to be accessible in the same filesystem as the proxy server which may be a bit of burden in the deployment process. Another approach is to configure the proxy-server to cache those requests after the first access to the proxied url with the application serving the assets for the first access (not cached by nginx yet). But this approach doesn't work well in nginx if nginx is also responsible for gzipping the assets. Applying gzip compression directly in the backend avoid having to configure a new proxy in the path just to compress the content before it gets cached.