Nginx Question posted in
The official documentation can be found here.

How to serve static gzipped javascript files in lighttpd? – Nginx

Background:
I have a small RaspberyPi-like server on Armbian (20.11.6) (precisely – on Odroid XU4).
I use lighttpd to serve pages (including Home Assistant and some statistics and graphs with chartjs).
(the example file here is Chart.bundle.min.js.gz)

Issue:
There seems to be a growing amount of javascript files, which become larger than the htmls and the data itself (some numbers for power/gas consumption etc.). I am used to use mod_compress, mod_deflate etc on servers (to compress files on the fly), but this would kill the Odroid (or unnecessarily load CPU and the pitiful SD card for caching).

Idea:
Now, the idea is, just to compress the javascript (and other static (like css)) files and serve it as static gzip file, which any modern browser can/should handle.

Solution 0:
I just compressed the files, and hoped that the browser will understand it…
(Clearly the link was packed in the script html tag, so if the browser would get that gz is a gzip… it should maybe work).
It did not 😉

Solution 1:
I enabled mod_compress (a suggested on multiple pages) and and tried to serve static js.gz file.
https://www.drupal.org/project/javascript_aggregator/issues/601540
https://www.cyberciti.biz/tips/lighttpd-mod_compress-gzip-compression-tutorial.html
Without success (browser takes it as binary gzip, and not as application/javascript type).
(some pages suggested enabling mod_deflate, but it does not seem to exist)

Solution 2:
(mod_compress kept on) I did the above, and started fiddling with the Content-Type, Content-Encoding in the HTML (in the script html tag). This did not work at all, as the Content-Type can be somehow influenced in HTML, but it seems that the Content-Encoding can not.
https://www.geeksforgeeks.org/http-headers-content-type/
(I do not install php (which could do it) to save memory, sd card lifetime etc.).

Solution 3:
I added "Content-Encoding" => "gzip" line to the 10-simple-vhost.conf default configuration file in the setenv.add-response-header. This looked as a dirty crazy move, but I wanted to check if the browser accepts my js.gz file… It did not.
And furthermore nothing loaded at all.

Question:
What would be an easy way to do it ? (without php).
Maybe something like htaccess in Apache ?

EDIT 1:
It seems that nginx can do it out-of-the-box:
Serve static gzip files using node.js
http://nginx.org/en/docs/http/ngx_http_gzip_static_module.html
I am also digging into the headers story in lighttpd:
https://community.splunk.com/t5/Security/How-to-Disable-http-response-gzip-encoding/m-p/64396

EDIT 2:
Yes… after some thinking, I got to the idea that it seems that this file could be cached for a long time anyway, so maybe I should not care so much 🙂

Tags:

2

Answers


  1. Chosen as BEST ANSWER
    0

    It seems that I was writing the question so long, that I was near to the solution.

    I created an module file 12-static_gzip.conf, with following content:

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

    I have not found any similar trick for lighttpd, so I applied here a similar solution which I would use for Apache. Expected behavior was, that it will just respond the Content-Encoding header for the gz files, without using php or any additional modules... and it works !!!

    The mod_compress module or any other of this kind is disabled and no other changes are needed.

    Clearly, the http negotiation is more complex, so I am not sure if this will work for all browsers, but it surely work very nicely for Chrome.

    I am also planning to create some ESP32 web servers, where drive and memory are even more critical, so I will try to apply similar solution.

    Nevertheless, the questions still hold...
    is there a better/cleaner solution ?
    Are there some caveats to be expected ? Browser compatibility etc. ?


  2. 0

    Your solution (below) to set the response header is a workable one for your situation.

    However, I would recommend using lighttpd mod_deflate with deflate.cache-dir (lighttpd 1.4.56 and later)

    When configured properly, lighttpd will serve gzipped Content-Encoding to clients which support the compression, and lighttpd will serve plain content to clients which do not support the compression. lighttpd will compress each file as it is served and will save the compressed file in deflate.cache-dir so that lighttpd does not have to re-compress the file the next time the file is requested. lighttpd will detect if the original file has changed and will re-compress it into the cache the next time the file is requested.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search