From 178ba024fea4db2b91fd159da629f0a8588f119a Mon Sep 17 00:00:00 2001
From: Matthew Holt <mholt@users.noreply.github.com>
Date: Sat, 28 Mar 2020 19:07:51 -0600
Subject: [PATCH] httpcaddyfile: Put root directive first, before redir and
 rewrite

See https://caddy.community/t/v2-match-any-path-but-files/7326/8?u=matt

If rewrites (or redirects, for that matter) match on file existence,
the file matcher would need to know the root of the site.

Making this change implies that root directives that depend on rewritten
URIs will not work as expected. However, I think this is very uncommon,
and am not sure I have ever seen that. Usually, dynamic roots are based
on host, not paths or query strings.

I suspect that rewrites based on file existence will be more common than
roots based on rewritten URIs, so I am moving root to be the first in
the list.

Users can always override this ordering with the 'order' global option.
---
 caddyconfig/httpcaddyfile/directives.go | 11 +++++++++--
 modules/caddyhttp/caddyhttp.go          |  2 ++
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/caddyconfig/httpcaddyfile/directives.go b/caddyconfig/httpcaddyfile/directives.go
index ba8f4387d..4c2b2d91b 100644
--- a/caddyconfig/httpcaddyfile/directives.go
+++ b/caddyconfig/httpcaddyfile/directives.go
@@ -27,14 +27,21 @@ import (
 
 // directiveOrder specifies the order
 // to apply directives in HTTP routes.
+//
+// The root directive goes first in case rewrites or
+// redirects depend on existence of files, i.e. the
+// file matcher, which must know the root first.
+//
+// The header directive goes second so that headers
+// can be manipulated before doing redirects.
 var directiveOrder = []string{
+	"root",
+
 	"header",
 
 	"redir",
 	"rewrite",
 
-	"root",
-
 	// URI manipulation
 	"uri",
 	"try_files",
diff --git a/modules/caddyhttp/caddyhttp.go b/modules/caddyhttp/caddyhttp.go
index 4fd09a231..6666d3eb0 100644
--- a/modules/caddyhttp/caddyhttp.go
+++ b/modules/caddyhttp/caddyhttp.go
@@ -199,6 +199,8 @@ func StatusCodeMatches(actual, configured int) bool {
 
 // tlsPlaceholderWrapper is a no-op listener wrapper that marks
 // where the TLS listener should be in a chain of listener wrappers.
+// It should only be used if another listener wrapper must be placed
+// in front of the TLS handshake.
 type tlsPlaceholderWrapper struct{}
 
 func (tlsPlaceholderWrapper) CaddyModule() caddy.ModuleInfo {