0

I currently compile my assets with Webpack's BrotliPlugin, which creates a separate file, brotli-encoded, i.e.:

  • style.css
  • style.cssb

Here's what I want to achieve: Consider the HTML page requests style.css.

IF

  • The user sent br into its Accept-Encoding request header
  • AND the corresponding brotli file exists (style.cssb in this case):

THEN

  • Serve the corresponding brotli file content style.cssb
  • With a Content-Type: text/css response header
  • With a Content-Encoding: br response header

OTHERWISE

  • Act as normal, just serve style.css

Here's part of my config so far:

map $http_accept_encoding $accepts_brotli {
    default false;
    "~*br" true;
}
location ~* (.*).(css|js)$ {
    set $brotli_uri "${uri}b";
    set $brotli_file "${request_filename}b";
    set $should_use_brotli "";
    if ($accepts_brotli = true) {
        set $should_use_brotli "Y";
    }
    if (-f $brotli_file) {
        set $should_use_brotli "${should_use_brotli}Y";
    }
    if ($should_use_brotli = YY) {
        add_header X-URI $brotli_uri;
        add_header Content-Encoding br;
    }

    add_header X-FOO "bar";
    try_files $brotli_uri $uri;
}

Result:

  • X-URI is present in response
  • X-FOO is not
  • Uncompressed content is still served

What am I doing wrong?

Ben
  • 101
  • PS: I'd like to avoid Nginx' brotli plugin since I can compute compression at compile time, which prevents CPU overhead upon each request. – Ben Dec 06 '19 at 15:49
  • There is brotli_static directive to serve precompressed files https://github.com/google/ngx_brotli/blob/master/README.md#brotli_static – Alexey Ten Dec 06 '19 at 22:40
  • Oh nice, I didn't notice this. Thanks! – Ben Dec 09 '19 at 14:04

0 Answers0