如何在 lighttpd 中提供静态 gzipped javascript 文件？答案

【问题标题】：How to serve static gzipped javascript files in lighttpd?如何在 lighttpd 中提供静态 gzipped javascript 文件？
【发布时间】：2021-04-20 23:35:00
【问题描述】：

背景：
我在 Armbian (20.11.6) 上有一个类似 RaspberyPi 的小型服务器（准确地说 - 在 Odroid XU4 上）。我使用 lighttpd 来提供页面（包括 Home Assistant 和一些带有 chartjs 的统计数据和图表）。（这里的示例文件是 Chart.bundle.min.js.gz）

问题：
似乎越来越多的 javascript 文件变得比 htmls 和数据本身更大（一些用于电力/气体消耗等的数字）。我习惯在服务器上使用 mod_compress、mod_deflate 等（即时压缩文件），但这会杀死 Odroid（或不必要地加载 CPU 和用于缓存的可怜的 SD 卡）。

想法：
现在，想法是，只是压缩 javascript（和其他静态（如 css））文件并将其作为静态 gzip 文件提供，任何现代浏览器都可以/应该处理。

解决方案 0：
我只是压缩了文件，希望浏览器能理解... （显然，该链接被打包在 script html 标记中，因此如果浏览器知道 gz 是 gzip ......它应该可以工作）。它没有;)

解决方案 1：
我启用了 mod_compress（在多个页面上建议）并尝试提供静态 js.gz 文件。
https://www.drupal.org/project/javascript_aggregator/issues/601540
https://www.cyberciti.biz/tips/lighttpd-mod_compress-gzip-compression-tutorial.html
没有成功（浏览器将其视为二进制 gzip，而不是应用程序/javascript 类型）。（有些页面建议启用 mod_deflate，但似乎不存在）

解决方案 2：
（mod_compress 继续）我做了上面的事情，并开始摆弄 HTML 中的 Content-Type、Content-Encoding（在脚本 html 标记中）。这根本不起作用，因为 Content-Type 在 HTML 中可能会受到某种影响，但似乎 Content-Encoding 不能。
https://www.geeksforgeeks.org/http-headers-content-type/
（我不安装 php（它可以做到）以节省内存、sd 卡寿命等）。

解决方案 3：
我在 setenv.add-response-header 中的 10-simple-vhost.conf 默认配置文件中添加了“Content-Encoding”=>“gzip”行。这看起来是一个肮脏的疯狂举动，但我想检查浏览器是否接受我的 js.gz 文件......它没有。
而且根本没有加载任何内容。

问题：
有什么简单的方法可以做到这一点？（不带 php）。
也许像 Apache 中的 htaccess 之类的？

编辑 1：
看来 nginx 可以开箱即用：
Serve static gzip files using node.js
http://nginx.org/en/docs/http/ngx_http_gzip_static_module.html
我也在挖掘 lighttpd 中的标题故事：
https://community.splunk.com/t5/Security/How-to-Disable-http-response-gzip-encoding/m-p/64396

编辑 2：
是的...经过一番思考，我想到这个文件似乎可以被缓存很长时间，所以也许我不应该太在意:)

【问题讨论】：

标签： javascript gzip lighttpd

【解决方案1】：

您设置响应标头的解决方案（如下）适合您的情况。

但是，我建议将 lighttpd mod_deflate 与 deflate.cache-dir 一起使用（lighttpd 1.4.56 及更高版本）

如果配置正确，lighttpd 将为支持压缩的客户端提供压缩的内容编码，而 lighttpd 将为不支持压缩的客户端提供纯内容。 lighttpd 将在提供每个文件时对其进行压缩，并将压缩文件保存在deflate.cache-dir 中，以便下次请求文件时 lighttpd 不必重新压缩文件。 lighttpd 将检测原始文件是否已更改，并在下次请求文件时将其重新压缩到缓存中。

【讨论】：

是的，我确实在“普通”服务器上使用它，以缩短加载时间。现在这里确实存在缺点，主要是由于丰富的 CPU 能力和强大的硬盘驱动器（或更多 RAM，带有 RAM 缓存目录）。 RaspberryPI 或 ESP32 既没有丰富的 CPU 也没有强大的硬盘驱动器（通常是 SD 卡，或者一些内置闪存）。这就是为什么我试图避免这种情况。尽管如此，经过一番阅读，由于负载非常小（只有家庭流量），这可能仍然是最可行的解决方案。我会试一试。谢谢！

【解决方案2】：

看来我写的问题太久了，我已经接近解决方案了。

我创建了一个模块文件12-static_gzip.conf，内容如下：

$HTTP["url"] =~ ".gz" {
    setenv.add-response-header = (
        "Content-Encoding" => "gzip"
    )
}

我没有发现任何类似的 lighttpd 技巧，所以我在这里应用了一个类似的解决方案，我将用于 Apache。预期的行为是，它只会响应 gz 文件的 Content-Encoding 标头，而不使用 php 或任何其他模块... 它可以工作！！！

mod_compress 模块或任何其他此类模块已禁用，无需进行其他更改。

显然，http 协商更复杂，所以我不确定这是否适用于所有浏览器，但它肯定适用于 Chrome。

我还计划创建一些 ESP32 Web 服务器，其中驱动器和内存更为关键，所以我会尝试应用类似的解决方案。

尽管如此，问题仍然存在......
有没有更好/更清洁的解决方案？
是否有一些警告？浏览器兼容性等？

【讨论】：