v4.0.0

Release 4.0.0

URL origins between stanzas are now checked for duplicates

When working with large EZproxy config files, it is important to avoid having conflicting "Starting Point URLs". It can be confusing to have two stanzas for the same combination of scheme (http:// or https://) and domain name, which is called an origin. If two stanzas both include the same origin, it can make debugging access issues more difficult.

In previous releases, only Host (H) and HostJavaScript (HJ) directives were checked between stanzas to make sure they did not have conflicting origins. Now, URL directives are also checked to make sure they don't match an origin from a previously processed stanza.

Importantly, URL origins are not checked against Host or HostJavaScript origins in the same stanza, since many existing stanzas have a Host or HostJavaScript directive which covers the origin in the URL directive.

Duplicate origins in Host and HostJavaScript directives within a stanza are allowed by default

Host and HostJavaScript origins in one stanza can now be duplicated. For example, as of 2025-10-06, the OCLC supplied JSTOR stanza has a duplicate https://uk.jstor.org origin in the HJ directives. In previous releases, this would trigger a L2002 warning. In this release, this would not trigger a warning, unless the new CLI option -origins is used. If it is, then the duplicate origin would trigger a new L2005 warning.

We hope that this change makes the linter output less noisy by default for OCLC supplied stanzas, making more serious issues easier to find.

ProxyHostnameEdit processing improvements

ProxyHostnameEdit checks, enabled with the -phe flag, have been improved. They no longer rely on deep-to-shallow ordering to ensure PHE directives don't interfere. Now, each PHE find parameter is checked to make sure previously seen find parameters are not a suffix match.

For example:

ProxyHostnameEdit cshlp.org$ cshlp-org
ProxyHostnameEdit www.cshlp.org$ www-cshlp-org
ProxyHostnameEdit www.cshlpress.org$ www-cshlpress-org

If this config were used to process www.cshlp.org, the first line would match first, and the hostname would be transformed to www.cshlp-org. This would not match the second line. The full hostname would not be processed, and the leading www. would cause HTTPS errors.

Before this release, the solution to this problem was to order all PHE lines in deep-to-shallow ordering, like so:

ProxyHostnameEdit www.cshlp.org$ www-cshlp-org
ProxyHostnameEdit www.cshlpress.org$ www-cshlpress-org
ProxyHostnameEdit cshlp.org$ cshlp-org

This was correct, but messy, since www.cshlp.org and cshlp.org lines were not next to eachother.

In this release, one can use

ProxyHostnameEdit www.cshlp.org$ www-cshlp-org
ProxyHostnameEdit cshlp.org$ cshlp-org
ProxyHostnameEdit www.cshlpress.org$ www-cshlpress-org

since the PHE check now relies on suffix matching instead.

Acknowledgments

Big thanks to @moorereason for their work on this release!

Changelog

• 50a7cb9 Add binary to .gitignore
• c28323a Add testdata for individual options
• 4274419 Change how H and HJ origins are processed.
• 1ff4646 Fix typo is test file name
• 4458d9c Improve ProxyHostnameEdit logic
• e80db72 Improvements on processing origins in URLs.
• 3308701 Minor linting issue fix for godot
• fa0cc10 Move PHE tests to the correct test file
• 92ed5c8 Refactor PHE tracking to use regexp matching