v2.34.0

[joseluisq]

This new v2.34.0 release brings several security and bug fixes. Better X-Forwarded-For handling and other improvements.

Breaking

• URL Redirects/Rewrites: Single Glob wildcard (*) will no longer match a path separator (/) in source but double wildcard (**) can be used instead if wanted. See docs below.
• Log Remote Address: log-remote-address option will no longer log from the X-Forwarded-For header by default. It has to be opted-in together with the new log-forwarded-for option. See docs below.

Fixes

• 93479ba Bugfix/security dependency updates including tokio, rustls, regex, tracing, flate2, serde, async-compression and other crates. PR Update dependencies 28.10.2024 #502.
• 4ed4bb4 Docker: Update Alpine (3.19.4) and Debian (12.8) Docker images. PR Update Alpine (3.19.4) and Debian (12.8) Docker images #505.
• 0768c20 CI: Update deprecated macos-12 Github Actions runner to macos-14.

Features

• 13e3f38 Better X-Forwarded-For handling via the new log-forwarded-for and trusted-proxies options. PR Improve X-Forwarded-For handling #495 by @Jeidnx. See docs.

Refactorings

• 96ed7df breaking: Prevent single Glob wildcard (*) from matching a path separator (/) in URL Redirect's source. PR Prevent single wildcards from matching path separators for URL Redirects #501 by @mschoettle. See docs.
• 2737f4c breaking: Prevent single Glob wildcard (*) from matching a path separator (/) in URL Rewrite's source. PR Prevent single wildcards from matching path separators for URL Rewrites #506 by @mschoettle. See docs.
• 5516b6a Misc: Improve tests for URL Redirects feature. PR Add additional tests for URL Redirect feature #503 by @mschoettle.

Docs

• e1a73c0 Add contributing, code of conduct and code guidelines pages.
• 12387a8 Improve docs configuration and fix some anchor links. PR Improve docs configuration and fix anchor links #504 by @mschoettle. See docs.
• cd11bd6 Replace the deprecated TrueNAS Scale option with TrueCharts. PR Truenas deprecated #486 by @ctag. See docs.

For more details see the v2.34.0 milestone and the full changelog v2.33.1...v2.34.0.

---

This discussion was created from the release v2.34.0.

[HejdesGit]

Hi!

Thank you for all the fantastic work you’re doing, it’s truly appreciated!

I have a quick question regarding the breaking changes. Shouldn’t these changes classify this as a major release according to semantic versioning, or am I misunderstanding something?
We are using joseluisq/static-web-server:2-alpine in our docker file and this breaks things for us.

Just wanted to hear your thoughts.

Br,
Johan

[mschoettle]

Hi Johan,

I came across this interesting article a few months ago. Someone posted it in a discussion on another project: https://hynek.me/articles/semver-will-not-save-you/

SemVer aside, I highly recommend to pin your dependencies to the exact version. Then use a tool like Renovate Bot to receive updates to dependencies via PRs. The PRs will contain the release notes of the new version. An example can be seen here: mschoettle/website#54

[joseluisq]

Yes absolutely. You are right on this @HejdesGit. It should have been a reason to bump up to a major v3 according to Semver (what the project follows). But honestly, since this is a minor breaking change (also communicated in the release) with an easy migration change (the other about logs does not have an impact per se), I didn't want to leave this change to be shipped on a long major v3 in the future. Even if done today, leave v2 in a grace period of maintenance as a result or maintain two versions. Also, if I could think about bumping to a major v3, I could use it as an excuse to ship more breaking changes and encourage users to do the upgrade which will be worse for users at this point.

That's why I accepted to ship it as part of v2.43.0 so here we are. Of course, this is not a nice thing to do for users who rely on a stable v2 Semver-based. It is a trade-off. But we will work to make sure to don't do it on the next releases.

We want to keep maintaining v2 and leave it in favor of v3 only when we really can not maintain it anymore or there are structural changes that deserve a major change.

Anyway, in that regard, we will enforce our rules (also adopting tooling) to not jump into such situations anymore.

Thanks for pointing that out.
Your feedback is appreciated.

[HejdesGit]

Hi, and thanks for the answer and article, @mschoettle

There are some points I agree with and some that I disagree with, but overall, it's an interesting article. In short, my stance is that semantic versioning is not an absolute rule for avoiding breaking changes, but it’s helpful.

Renovate Bot is a nice tool, and I agree that tooling can help with the problem. Pinning the exact version and using Renovate Bot for updates for joseluisq/static-web-server would be a nice solution if we just look at this example. But on a larger scale, I’m guessing that it would be time-consuming to perform updates. We have lots of repositories and lots of packages in those repositories. Getting a PR for every release and reading whether there are breaking changes would take some time. But like I said, I’m just guessing—please correct me if I’m wrong on this.

[HejdesGit]

I appreciate the explanation and I understand that versioning can be tricky.

Good luck in the future and thanks for all your hard work @joseluisq

[mschoettle]

@HejdesGit

Renovate Bot is a nice tool, and I agree that tooling can help with the problem. Pinning the exact version and using Renovate Bot for updates for joseluisq/static-web-server would be a nice solution if we just look at this example. But on a larger scale, I’m guessing that it would be time-consuming to perform updates. We have lots of repositories and lots of packages in those repositories. Getting a PR for every release and reading whether there are breaking changes would take some time. But like I said, I’m just guessing—please correct me if I’m wrong on this.

You are right when it comes to using the default configuration. Depending on the state of a project (let's assume that the dependencies are somewhat outdated) you would get "spammed" with a lot of PRs (though they do get rate-limited). The other thing is that the other team members have to be on board with this. Otherwise, no one will want to look at those PRs and merge them. In general, I would say it highly depends on the project. If it already has a pipeline and good test coverage it helps a lot in having some level of confidence that an update does not break anything. As soon as manual work is included it will get procrastinated, happens to me too :)

What I like about Renovate is that it is highly configurable (besides supporting many different package managers). There are lots of options to configure it. For example, it is possible to group dependency updates, or, not create PRs but have them be approved first on the "Dependency Dashboard". See: https://docs.renovatebot.com/getting-started/use-cases/#advanced-configuration

The Renovate documentation has a good best practices guide which I find quite helpful from this section onwards: https://docs.renovatebot.com/upgrade-best-practices/#why-updating-often-is-easier-faster-and-safer
Further down are recommendations for projects with severely out-of-date dependencies.

Hope this helps! Happy to answer more questions on this if you have any.

[matt-sneed]

so we ran into this breaking change unintentionally due to not locking our docker version to the *.33.1 version and found that out the hard way in our production instances. that's been since fixed.

the issue we have is the current documentation on the glob patterns doesn't seem to align correctly with the actual behavior.

our previous rewrite rule that worked on 2.33.1 is:

[[advanced.rewrites]]
source = "/a/prefix/{**}"
destination = "/$1"

the purpose was to route all traffic that was prefixed with "/a/prefix" and direct that traffic to the public root.
i.e.
/a/prefix/index.html -> ./public/index.html
/a/prefix/js/index.bundle.js -> ./public/js/index.bundle.js

after taking the 2.34 release we had to modify our rewrite rules to the following to make it continue working, and for the life of me I can't figure out why it should work because it doesn't seem to follow normal glob pattern matching.

[[advanced.rewrites]]
source = "/a/prefix/**/{**}"
destination = "/$1$2"

[joseluisq]

@matt-sneed I wonder why your pattern /a/prefix/{**} does not work for you because it should. Even after 2.34.0, the behavior of ** should be the same as the previous release. Because the actual change that differs in the current release is about the single * wildcard not matching a path separator. But the behavior of the ** should remain.

If ** does not work as before then please file an issue to ding into it.