When thy variables henceforth accept blessed white-space,
guided will thy scripture be along righteous path(s).
-- 4 BASH 3:42
Caddy's dist files sometimes ended up being owned by matt:staff or other
quite arcane and/or frightening names. If someone extracting didn't pay
attention a regular user who happened to have same uid by accident could
later tamper with the files' contents. It's 0:0 from now on.
Use all available threads when packaging distributables
Caddy binaries will be added to their archives in-place: This change
eliminates them being renamed within dist/builds one after another.
As does 'gox', dist/automate.sh will spare one available thread if possible.
Format of main.buildDate has been locale-dependent,
and is now ISO-8601 compliant.
Caddy displayed with ```-version``` something like (mind the datetime format):
Caddy 0.8.2 (+591b209 Fri Mar 18 21:22:55 UTC 2016)
2 files changed, 9 insertions(+), 4 deletions(-)
build.bash
main.go
which is now:
Caddy 0.8.2 (+591b209 2016-03-18 21:22:55Z)
2 files changed, 9 insertions(+), 4 deletions(-)
build.bash,main.go
See also:
* http://wiki.bash-hackers.org/scripting/obsolete
* https://google.github.io/styleguide/shell.xml
* https://xkcd.com/1179/
Unlike network.target the network-online.target guarantees that the network
devices are online.
If you bind to 0.0.0.0, [::], [::1], and/or 127.0.0.1 only that is enough to
proceed. But in case a particular IP is needed, like ${COREOS_PUBLIC_IPV4},
we require any IP assignments to have completed before Caddy's start. That
is achieved by depending on systemd-networkd-wait-online.service (which is
scheduled before network-online.target, then, automatically).
Add systemd service file for caddy
Add some README with basic setup instructions
Explain how to view the service configuration
Add a note about permissions
Add a comment about run user and group
service->service unit
A systemd service can consist of different units. A unit configuration
file has the `.service` file ending which is a bit confusing, so please
be considerate if I'm confusing `service` and `unit` in the README
Fix typos/reword
Add contact information
- The mime middleware used filepath where it should arguably use path.
- Changed the configuration to use a map instead of scanning an array
during every request. The map is static (after configuration), so
should be fine for concurrent access.
- Catch duplicate extensions within a configuration and error out.
- Add tests for new error case.
Minor change to server/server.go such that /.well-known/acme-challenge
can be passed through when TLS.Manual is true on the vhost the request
came in through.
fastcgi's ServeHTTP method originally returned the correct value (0) in
b51e8bc191. Later, I mistakenly suggested
we change that to return the status code because I forgot that status
codes aren't logged by the return value. So fastcgi broke due in
3966936bd6 due to my error.
We later had to try to make up for this with ugly Content-Length checks
like in c37ad7f677. Turns out that all we
had to do was fix the returned status here back to 0. The proxy
middleware behaves the same way, and returning 0 is correct. We should
only return a status code if the response has not been written, but with
upstream servers, we do write a response; they do not know about our
error handler.
Also clarifed this in the middleware.Handler documentation.
