The function `HostHost` is an obvious typo, such a function does not
exist, most likely just `Hosts` is meant here.
Furthermore, Trafik 3 doesn't use the Gorilla Mux framework
anymore, therefore the matching using curly brace syntax like in
`{subhost:[a-z]+}` isn't supported anymore. For details, see [1].
Alas, the final Traffic 2 to 3 migration document dropped this crucial
information but at least all of those many examples using this method
which were in the Trafik 2 documentation were removed from the Traefik 3
documentation.
Also `[a-z]+` does not match all valid sub-domains as specified per RFC
1123 [2], and needs to be enhanced to support hyphen characters within a
single DNS label as well (but not at the start or the end of a label).
This is also a requirement for i18n domains in their ACE representation.
Actually the regular expression can be made even more strict to comply
with length limitations as defined in RFC 2181 [3] but this would require
pretty resource-intense lookarounds in the regular expression, therefore
those should be neglected here.
As we are doing regular expression match anyway, the `Host` function can
be dropped. It adds redundancy to the configuration and only would make
sense from a performance point of view, if the vast majority of requests
would lack any sub-domain.
Last but not least, the Trafik documentation isn't clear at all, whether
any potential port number is being stripped from the `Host` request header.
From empiric testing with Traefik 3.0.1 that's apparently the case, but
as it isn't a documented feature, we rather accept potential ports as
well.
Same when it comes to case-sensitivity. From testing it looks like the
hostname is always forced to lower-case chararcters, but strangely
enough even the official documentation contains an example which
suggests enabling case-insensitive mode for regular expression matching
using `(?i)`. Therefore we better stick with that one as well.
[1] https://traefik.io/blog/traefik-proxy-3-0-scope-beta-program-and-the-first-feature-drop/
[2] https://datatracker.ietf.org/doc/html/rfc1123
[3] https://datatracker.ietf.org/doc/html/rfc2181
Alas over time the versioning schema of image tags by
`lscr.io/linuxserver/heimdall` changed several times, ranging from
simply incrementing a counter to a ISO 8601 date-alike variant to
finally something which comes close the semantic versioning.
With the default rule set, Renovate gets fooled by the ISO 8601 date
variant which was used in year 2021. The idea is to use a regular
expression for better matching which kicks out 2021 using a negative
lookahead and also require a minor version number in order not to get
caught by the counter-like increments.
As a test, the image tag is intentionally set to `2.6.0` while `2.6.1`
would be the latest release. This is just to verify whether Renovate
does to right thing now.
