Problem with assets optimization, relative links and integrity check

Support
, ,
1

Hi there,

I’m running Hugo on Netlify, and I’ve stumbled on a weird bug with assets optimization.

I’m using Hugo’s built-in function which allows to use an integrity check attribute on my JavaScript assets. I also have assets optimization set to ON in my Netlify dashboard. When using absolute URLs in my website, everything is working fine. But when I use relative URLs, it seems that Netlify injects Cloudflare’s URLs and this breaks the integrity check, therefor creating a CORS problem (and blocking my site’s JavaScript).

I’ve raised the issue on Hugo’s forums here: CORS issue when using RelPermalink on integrity check - support - HUGO

Is there something that needs to be done on my end?

2

hi @fbnlsr - have you tried setting the asset optimization to OFF? does that change things?

3

It does. Whenever I set optimization to OFF, the problem disappears.

Is there any way to use absolute URLs on assets with optimization to ON?

4

so here is something interesting: hugo actually has some known trickyness in how it handles URLs that might be part of the problem.

Give this thread a read through - maybe there is a solution in here:

5

Well, would you look at that!

I added a trailing slash to my base URL in my config file and activated assets optimization back ON and it works!

As a precaution, I checked the deploy that was causing me troubles and it… also works? I don’t know what to think now. :thinking:

1 Like
6

oh man. that is really something. well, i’m glad it works now!!

7

Nevermind, the cache must have been still ON on Netlify’s side. It’s not working.

So I had to turn assets optimization OFF again. :sob:

8

The issue is probably not the trailing slash, but the leading slash. /posts points to the posts subdirectory at the top level of your content, or posts.html – depending on your set up. posts (without the leading slash) points to the posts directory or posts.html in whatever subdirectory you happen to be in, as mentioned above by @perry.

9

@gregraven the problem comes from the JavaScript assets and their integrity check, not the pages. When using Netlify’s assets optimization, they mess things with Hugo’s fingerprint, thus triggering a CORS violation.

10

Yup - when we optimize, we move to cloudfront, which won’t match your domain name. For most folks’ sites this isn’t a big deal, but clearly your settings are special. I use hugo with optimization myself and it’s no problem, but I use a BaseURL of / and presumably some other settings are different as well.

At any rate, since we won’t be changing how we process assets in the foreseeable future, you’ll want to not use our asset optimization in case you have strict requirements about URL’s. There is no version of our processing intended or available today that does NOT rewrite to cloudfront. If you’re trying to turn it off please make sure that “disable processing” is checked, rather than just unchecking the other boxes in that asset optimization section of our UI. Those are different - we’ll still rewrite some URL’s if you don’t completely disable our optimization!

Nothing we do is very fancy, you could do it yourself easily using npm modules that are potentially better than the ones we use. The workflow we use is something like this:

  1. take an asset fingerprinted name for the file, deploy it with very long cache timeouts (1 year). IF the asset changes, so will the path, so the long cache is ok despite our general advice not to monkey with cache timeouts
  2. bundle CSS and JS appropriately (we make one bundle per “set” of files included in any other file - so it’s not “one bundle for all” but “commons.js + styles.js for most pages, commons.js+styles.js+special-for-one-page.js for the one-page, and no bundle if there is only one JS file used”)
  3. if you want Pretty URL’s, we create redirects from /page/index.html to /page/ and also rewrite the referring html, js, and css to point to /page/ directly (in case you had links to /page/index.html)
1 Like
11

Thanks a lot @fool for taking the time to write this thorough explanation. I’ll mark my problem as solved as it’s clearly a conflict between my Hugo settings and what Netlify is doing. In the end, no one’s to “blame”, it’s just something that’s a bit of an edge case. In fact, it might be useful to add this to Hugo’s documentation.

Anyways thanks again everyone for your help everyone!

1 Like