* If upstreams are all using same host but with different ports
ie:
foobar:4001
foobar:4002
foobar:4003
...
Because fnv-1a has not a good enough avalanche effect
Then the hostByHashing result is not well balanced over
all upstreams
As last byte FNV input tend to affect few bits, the idea is to change
the concatenation order between the key and the upstream strings
So the upstream last byte have more impact on hash diffusion
This commit replaces the use of github.com/smallstep/cli to generate the
root and intermediate certificates and uses go.step.sm/crypto instead.
It also upgrades the version of github.com/smallstep/certificates to the
latest version.
certmagic.New takes a template and returns pointer to the new config.
GetConfigForCert later must return a pointer to the new config not the
template.
fixes#5162
* reverseproxy: Mask the WS close message when we're the client
* weakrand
* Bump golangci-lint version so path ignores work on Windows
* gofmt
* ugh, gofmt everything, I guess
* ci: set least privilged token for github actions
Signed-off-by: Ashish Kurmi <akurmi@stepsecurity.io>
* ci:reverting github actions permissions for all but lint workflow
Signed-off-by: Ashish Kurmi <akurmi@stepsecurity.io>
* Incresed sleep between retries to reduce flakey tests in CI
* Also changed wait time for admin
* Modified time to make it more reliable
Co-authored-by: Mohammed Al Sahaf <msaa1990@gmail.com>
* fileserver: Reject ADS and short name paths
* caddyhttp: Trim trailing space and dot on Windows
Windows ignores trailing dots and spaces in filenames.
* Fix test
* Adjust path filters
* Revert Windows test
* Actually revert the test
* Just check for colons
* httpcaddyfile: Skip some logic if auto_https off
* Try removing this check altogether...
* Refine test timeouts slightly, sigh
* caddyhttp: Assume udp for unrecognized network type
Seems like the reasonable thing to do if a plugin registers its own
network type.
* Add comment to document my lack of knowledge
* Clean up and prepare to merge
Add comments to try to explain what happened
* Allow version to be set manually
When Caddy is built from a release tarball (as downloaded from GitHub),
`caddy version` returns an empty string. This causes confusion for
downstream packagers.
With this commit, VersionString can be set with eg.
go build (...) -ldflags '-X (...).VersionString=v1.2.3'
Then the short form version will be "v1.2.3", and the full version
string will begin with "v1.2.3 ".
* Prefer embedded version, then CustomVersion
* Prefer "unknown" for full version over empty
Co-authored-by: Matthew Holt <mholt@users.noreply.github.com>
* logging: Perform filtering on arrays of strings (where possible)
* Add test for ip_mask filter
* Oops, need to continue when it's not an IP
* Test for invalid IPs
This is something that has bothered me for a while, so I figured I'd do something about it now since I'm playing in the logging code lately.
The `console` encoder doesn't actually match the defaults that zap's default logger uses. This makes it match better with the rest of the logs when using the `console` encoder alongside somekind of filter, which requires you to configure an encoder to wrap.
Since all Windows services are run from the Windows system directory,
make it easier for users by switching to our program directory right
after the start.
PR #4066 added a dark color scheme to the file_server browse template.
PR #4356 later set the links for the `:visited` pseudo-class, but did
not set anything for the dark mode, resulting in poor contrast. I
selected some new colors by feel.
This commit also adds an `a:visited:hover` for both, to go along with
the normal blue hover colors.
It was not accurate. Placeholders could be used in outputs that are
defined in the same mapping as long as that placeholder does not do the
same.
A more general solution would be to detect it at run-time in the
replacer directly, but that's a bit tedious
and will require allocations I think.
A better implementation of this check could still be done, but I don't
know if it would always be accurate. Could be a "best-effort" thing?
But I've also never heard of an actual case where someone configured
infinite recursion...
Reported on commit e3e8aabbcf
Abused this change in some bash for loops to rapidly reload config
while making requests and didn't observe any memory or resource leaks.
