Using Hugo Pipes for CSS Minification Fails to Load on Proxy Servers

support
1

Curious if this is a known issue / quirk of proxy servers, but any site I run through hugo pipes for minification and fingerprinting will not properly load the CSS on [most] proxy servers. I uncovered this recently trying to troubleshoot what ended up being a strange local cache issue, but I was wondering if anyone had any insight into why this would be? Is it the additional extension added to the filename possibly? The CSS loads fine with no minification / fingerprinting run on all proxy servers.

Secondly, is this something I should even worry about? It seems to load fine on any other device and browser.

Thank you for any help or insight!

1 Like
2

Iā€™m interested in learning more about how those interact with Hugo, if anyone has experience.

Say, could you share more into about the setups you use? Which kinds of proxies? I ask because this didnā€™t occur to me, and Iā€™m wondering if some projects arenā€™t rendering correctly and I missed it.

3

So, there may be speficic issues with minificationg doing the wrong thing, but I fail to see how it could relate to proxy server.

4

Thanks for the questions! Iā€™m not sure what could be wrong with the minification, it loads fine on every device iā€™ve personally tested and many of these sites have been live and functioning for some time now until I came across this issue. It happens when I minify and fingerprint CSS or SASS files run through hugo pipes like this:

{{ $style := resources.Get "css/style.css" | minify | fingerprint }}

<link   rel="stylesheet"
        href="{{ $style.Permalink }}"
        integrity="{{ $style.Data.Integrity }}"
        media="screen">

or

{{ $sass := resources.Get "css/style.scss" }}
{{ $style := $sass | resources.ToCSS | minify | fingerprint }}

<link   rel="stylesheet"
        href="{{ $style.Permalink }}"
        integrity="{{ $style.Data.Integrity }}"
        media="screen">

You can see a site minified here: aggieadvocates.com

using most proxies it will render as if the CSS isnā€™t loading: https://www.hidemyass.com/en-us/proxy

but this proxy server is one of the few that still seems to render the page fine: kproxy[dot]com

compared to this project I did, without any minification, works fine on all proxiesā€¦ bastropcountryclub[dot]com

(sorry for the [dot] links - I can only post two links as a new user)

5

Iā€™ve narrowed down the issue to the Fingerprinting / Integrity. The majority of these proxy providers seem to not like something about that. Iā€™m not well-enough versed to answer why, but removing the integrity fixed it across the board - Minification still in use.

Suffice to say Iā€™d still like to know if anyone knows more about the extent of this ā€œissueā€ (I struggle to even call it that because I tested on ever ā€˜modernā€™ browser back to IE8 and wasnā€™t able to reproduce this issue outside of the proxy servers. But I also dont know if this would theoretically affect people using a VPN also then?

6

I was also able to confirm the integrity / fingerprinting can prevent the file from being properly loaded when using netlify branch subdomains. So itā€™s so to be something with the additional hashing on the file names.

7

How are you confirming? Are you comparing the hashes?

8

Tried the same code with and without integrity on the production branch (deployed to the root domain) and on a netlify brand subdomain (which uses the $deploy-prime-url) to add the staging link.

Works fine on production, but on staging the link isnā€™t loading- the hashes are the same, so thatā€™s not the issue.

Iā€™m not sure if these are related to the proxy failing to load, but I feel like it might be.

9

I canā€™t help, I donā€™t use half the things you are proposing creates an issue. Hereā€™s some observations, though:

  1. ā€œProxyā€ is a concept, not a standard. It makes sense some proxies will fail to load a fingerprinted resource; some might say that is by design.
  2. If you are having an issue with a Netlify sub-domain, you ought to contact them; theyā€™d want to know if fingerprinting wasnā€™t working correctly.
  3. Without your code repo, no one can reproduce this error (or no one else has noticed); I suggest you make it easy for another helper to reproduce your error. :slight_smile:

Ganbatte!

1 Like
10

This is a problem at CloudFlare Pages also. They are investigatingā€“very cooperatively.

For very long filenames of css CloudFlare Pages is incorrectly setting the mime type of the css files. They may set application/octet-stream or text/html. The correct type is text/css. Because the css file has the wrong mime type, most browsers will refuse to link the css to the site. Essentially the entire site will render poorly. There are layouts from theme, but all of the references to styles are broken.

I canā€™t say this is the problem you experienced at netlify, but it sounds similar.