Query-string module for Varnish Cache
I'm pleased to announce a new maintenance release of the 2.0 series, despite being very late to deliver. This new release adds support for the native REGEX type for VCL available since Varnish 6.6.0, letting the VCL compiler deal with the regular expressions setup and teardown.
Changelog:
Bootstrapped with:
I'm pleased to announce a new maintenance release of the 2.0 series. In this one nothing really happened except support for Varnish 6.5 that removed a deprecated function that was used so far. The breakage happened in Varnish's workspace API and the upgrade notes say this:
In general, accessing any field of
struct wsis strongly discouraged and if the workspace API doesn't satisfy all your needs please bring that to our attention.
So work was done to follow this guideline and only rely on appropriate functions. No functionality change, only a bit of refactoring to either work with the new goodies from the workspace API or emulate them otherwise. Continuous Integration was upgraded from Ubuntu 16.04 images to Ubuntu 20.04 and that lead to breaking builds of Varnish 6.0.0 and since the 6.0 series already had a couple security releases there's no point on giving up on improved compiler warnings to maintain compatibility with an obsolete version.
I would normally treat a compatibility breakage as a major change, but decided that having a baseline of 6.0.6 instead of 6.0.0 would not mandate a major release of this VMOD. In fact, I probably didn't break anything but I'm no longer committing to compatibility below 6.0.6 and of course non LTS releases of Varnish that are still supported.
Changelog:
Bootstrapped with:
I'm pleased to announce the first maintenance release of the 2.0 series. Indeed, nothing new under the sun, except that support for Varnish 6.2 was verified and should work out of the box.
The main change in this release is that the DPKG packaging is not longer considered experimental, and sbuild support was added as an additional option to build packages.
Other than that, both RPM and DPKG changelogs are no longer maintained to keep matters more simple.
Changelog:
Bootstrapped with:
I'm pleased to announce the first breaking release since the 1.0 redesign! While the 1.0 series has been a pleasure to work on, proving the redesign to be both more powerful and sustainable, this breaking changed needed to happen. So in retrospect, what's wrong with vmod-querystring 1.0? Nothing actually...
It's just that Varnish 4.1 should reach its End Of Life soon now that 6.0 is the new official LTS, and all of the 5.x series are already unsupported. By only supporting Varnish 6.0 and newer releases, it is now possible to make the URL argument optional too.
Taking the example from the manual:
import querystring;
sub vcl_init {
new qf = querystring.filter(sort = true);
qf.add_string("_"); # a timestamp used to bypass caches
qf.add_glob("utm_*"); # google analytics parameters
qf.add_regex("sess[0-9]+"); # anti-CSRF token
}
This snippet:
sub vcl_hash {
hash_data(qf.apply(req.url));
hash_data(req.http.host);
return (lookup);
}
Is now equivalent to this one:
sub vcl_hash {
hash_data(qf.apply());
hash_data(req.http.host);
return (lookup);
}
Since most of the time it is client requests that we can't trust, req.url is used when no URL is specified. In a backend subroutine that would be bereq.url instead.
So this release breaks build compatibility against older Varnish releases but doesn't break existing VCL. Instead it can be made more concise in most cases. Upgrading from a 1.0 release to 2.0 should be as simple as upgrading between 1.0 releases.
Changelog:
Bootstrapped with:
This is the first release with new features since the 1.0 release, and likely the last release to support Varnish 4.1!
The new feature is inspired by the uniq(1) command that breaks down its input into lines and folds together consecutive identical lines. So the querystring.filter() constructor now takes an optional uniq argument that defaults to false. Because the uniq(1) command only removes consecutive duplicates, it is often used in conjunction with the sort(1) command to achieve effective uniqueness. So when the order of parameters does not matter, it is possible to combine both sort and uniq options for even more determinism.
Speaking of sorting, this module no longer relies on qsort(3) to reorder query parameters because the POSIX standard makes it clear that it offers no stability guarantees:
If two members compare as equal, their order in the sorted array is unspecified.
With this release it is possible to sort query parameters but maintain the order of parameters with the same name when the order matters for the backend application. Another win for determinism!
Finally, the 1.0.5 release was already compatible with Varnish 6.1, it has been verified and 6.1 is now officially supported.
Changelog:
Bootstrapped with:
I am pleased to announce the 1.0.5 release of vmod-querystring. One more release with no new feature and only the necessary changes to support Varnish 6. While the Varnish team is working hard on squaring the API and ABI definitions for VMODs, this first step breaks previous assumptions when building modules.
As usual vmod-querystring is committed to build against all supported Varnish versions from a single release. This is still true from Varnish 4.1.3 to 6.0.0 with reasonable work around the Varnish changes in #include order.
Apologies for releasing Varnish 6 support one month after the Varnish 6 release, but there was no time to allocate to this project.
Fixes #38
One more release adding no new features and fixing no known bugs, except for build system bugs. It was a mistake to rely on the autoconf archive for anything, as the quality is overall much lower than autoconf itself. While revisiting the build system, it was a good occasion to rework how defaults are handled and they should be sane now:
./configure from a release archive is enough./bootstrap sets up anything needed for developmentOf course the possibility to override the defaults is still present.
The interesting part of this release is at its core: to deal with a purposeful API breakage in Varnish 5.1 (not technically breaking the ABI) a dirty hack involved disabling a GCC warning. The offending code was refactored and is no longer subject to the breakage at all, with added benefits:
As such, this module now advertises VRT compatibility, and should not need to be recompiled between minor Varnish updates. It was already safe, now it's officially safe.
Fixes #34 Fixes #36 Fixes #37
If French is your native language, you may get the joke.
Fixes #33
This release doesn't add any new features. It doesn't fix any bugs, except packaging bugs.
Debian packaging is still experimental, but thanks to packaging improvements it was tested successfully on Debian Stretch and Sid. For some reason building with pdebuild also worked for Ubuntu Xenial although it shouldn't, but failed for Yakkety and Zesty (whereas I expected it would). What pbuilder found in the repos doesn't seem to match the package database. Something to inspect later, it shouldn't block the release.
RPM packaging was slightly polished.
The main reason for this release is another release: Varnish 5.1.1 from last week. It breaks the API (but not the ABI) of the workspace facility. This release has been tested and builds fine with any Varnish release from 4.1.3 to 5.1.1 and hopefully future versions too.
This release doesn't add new Varnish features from 1.0, but instead focuses on integration.
From the changelog:
- Experimental debian packaging
- Continuous integration with Travis CI
- Code coverage with Codecov
- Library path for the test suite
So this is mainly a release that puts nice Travis and Codecov badges in the README, and turnkey DPKG packaging similar to what's been done for RPM: in the build tree or in a chroot using upstream tooling. Thanks to pdebuild/pbuilder I can now easily produce debian unstable debs on my Fedora box.
I hope Debian and Ubuntu users will find this useful, it certainly is for me.