Set session ticket keys properly (fixed in Go 1.8)

* fixing panic when root is symlink
checking root path is a symlink before os.Stat which panics

* fixing formatting

* adding test to verify symlink root path check

* fixing typo

* Add request placeholder support for querying request cookies.

This adds the ability to query the request cookies for placeholders
using the syntax "@cookiename".

For example, this would allow rewriting based on a cookie:
  rewrite {
    if @version is 'dev'
    to /dev/index.html
  }

* Switch cookie special char from @ to :

* Switch special char for cookies from : to ~

return 404 for "not a directory" errors

redirect: determine the FromScheme at runtime (#1297)

* Fix data race for max connection limiting in proxy directive.

The Conns and Unhealthy fields are updated concurrently across all active
requests.  Because of this, they must use atomic operations for reads and
writes.

Prior to this change, Conns was incremented atomically, but read unsafely.
Unhealthly was updated & read unsafely.  The new test
TestReverseProxyMaxConnLimit exposes this race when run with -race.

Switching to atomic operations makes the race detector happy.

* oops, remove leftover dead code.

Added Sourcegraph badge to README

httpserver: Register cgi plugin

Fix for #1388 starting with no Caddyfile

* Use new subdirectives and flatten rolling config

* Set default rotate config

* Set default rolling config (hopefully) errwhere

* Make private

* Flatten errors directive and remove c.IncrNest()

* Don't skip first error log roller subdirective we see

* Remove hadBlock

* Try lumberjack import

* Unname import

* Remote syslog

* golint

* Initialize mutex

Replace magic number 308 with http.StatusPermanentRedirect

Create only one log roller per file across whole process (fixes #1363)

httpserver: support QUIC reload

fix issue #958
Signed-off-by: Tw <tw19881113@gmail.com>

See issue #1371 for more information.

High improbability of being an actual problem. Logs are safe for
concurrent use, but os.Files are apparently not... Fixes #1371.

The standard lib pprof library doesn't set its own Content-Type header
properly. If pprof is used with gzip, the index endpoint will be
interpreted as a .gz file; so we force its hand and set the header.

Thanks to Kevin Froman (@beardog108) for the responsible heads up.

* Fix #1185

* Return normal path if no rewrite has happened

* Revert change, not required

* Updated tests

* proxy: use a new context for the outgoing request

fix issue #1345
Signed-off-by: Tw <tw19881113@gmail.com>

* proxy: add test for canceling the request
Signed-off-by: Tw <tw19881113@gmail.com>

proxy: Fixed #1352: invalid use of the HTTP hijacker

* Generate meta elements from useful front matters.
Limited to the default template and specific elements.

* Rerun gofmt

* Add "keywords" and remove "language" to/from the list of meta tags.

* Add a simple positive list test for the meta tag generation.

* Move the meta tag list to a var at the begin of the file.
Seperate the Meta tags from the other front matters:
	- Don't override user settings with name `meta`
	- Cleaner Code.

* Remove the uneccessary `[:]` in the []Bytes to String casting.
@mholt was right ;)

* One minor refinement. Combining two statements.

tls: Fix background certificate renewals that use TLS-SNI challenge

The loop which performs renewals in the background obtains a read lock
on the certificate cache map, so that it can be safely iterated. Before
this fix, it would obtain the renewals in the read lock. This has been
fine, except that the TLS-SNI challenge, when invoked after Caddy has
already started, requires adding a certificate to the cache. Doing this
requires an exclusive write lock. But it cannot obtain a write lock
because a read lock is obtained higher in the stack, while the loop
iterates. In other words, it's a deadlock.

I was able to reproduce this issue consistently locally, after jumping
through many hoops to force a renewal in a short time that bypasses
Let's Encrypt's authz caching. I was also able to verify that by queuing
renewals (like we do deletions and OCSP updates), lock contention is
relieved and the deadlock is avoided.

This only affects background renewals where the TLS-SNI(-01) challenge
are used. Users report seeing strange errors in the logs after this
happens ("tls: client offered an unsupported, maximum protocol version
of 301"), but I was not able to reproduce these locally. I was also not
able to reproduce the leak of sockets which are left in CLOSE_WAIT.
I am not sure if those are symptoms of running in production on Linux
and are related to this bug, or not.

Either way, this is an important fix. I do not yet know the ripple
effects this will have on other symptoms we've been chasing. But it
definitely resolves a deadlock during renewals.