Migrating from Jekyll to Hugo

Re:Migrating from Jekyll to Hugo by benatkin on Sunday June 24, 2018 @04:09PM (#17388162)

If you have a CDN or Varnish, they can provide eTags, and you don't need an md5 in the URL, except to save the browser from doing a GET request and getting a 304 Not Modified. A few Not Modified requests served by a fast server is worth the tradeoff of not having to deal with an asset pipeline, or worse, overly aggressive caching, which is common in asset pipeline environments where the cache settings designed for md5 tagged assets inevitably get applied to non-tagged assets.

[ Parent | on HN ]

Re:Migrating from Jekyll to Hugo by qw on Sunday June 24, 2018 @06:10PM (#17388649)

That would cause issues when deploying new versions. Even if the CDN or Varnish serves an updated etag, the browsers could potentially keep using an older version from its cache. Not what you want when you just fixed important bugs. This has happened to me, even without aggressive caching.

I suspect that even if you told the browser to revalidate on each request, you would end up in situations where the browser ignores it or is overruled by a corporate proxy.

With a md5 in the URL, the browser would be forced to make a new request.

[ Parent | on HN ]

Re:Migrating from Jekyll to Hugo by benatkin on Sunday June 24, 2018 @07:05PM (#17388853)

I've seen that happen, but I've seen people reset their browser caches because of misconfigured aggressive caching much more often.

IMO max-age=0, must-revalidate is a much better choice for the average website/blog owner.

For complex apps, setting up the asset pipeline can be worth the tradeoff. But Hugo is hardly a lower tier static site generator for not supporting this.

[ Parent | on HN ]

Re:Migrating from Jekyll to Hugo by nickjj on Monday June 25, 2018 @08:30AM (#17391810)

You can't shoot yourself in the foot with the md5 tagging approach. It completely solves cache invalidation in a simple way. That's why it's so popular.

When the content of your file changes you get a completely new file which has no cache headers associated to it. Then nginx caches the file forever, and when you make a change, a new file is created and the process repeats but if you don't make a change, then the same file is served from the user's local cache.

[ Parent | on HN ]