如何解决Caddy的重定向(redir)和重写(rewrite)的冲突
网站改版后，很难确保新的网址和旧的网址保持一致，因此总需要写一些重定向规则，确保原来被搜索引擎抓取的页面能重定向到新的URL。对于一个基于typeocho的php类型的网站，重写也总是必要的。在使用nginx服务器的时候，重写和重定向是在一起的，并没有什么歧义产生，但是，到caddy里边，这两个概念是区分开的。更为不好的地方在于，两者并存的时候，会出现意想不到的结果。
比如，最早本站发现有一些老页面的流量过来，但是会进到404页面。
5 203.208.60.50 - - [26/Aug/2018:20:53:44 +0800] "GET /article/223672015323021312 HTTP/1.1" 404 2057 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"按照官方说明，在Caddyfile中使用__redir__命令予以重定向。
redir 301 { /article/223672015323021312 /article/2017/06/php-git-http-server.html
/article/2017/06/5.html /article/2017/06/php-git-http-server.html
}
rewrite {
to {path} {path}/ /
}</code></pre><p>重启caddy，但是发现并没有生效，还是和之前效果一样。</p><!--more--><p>检查配置文件，发现应该是因为里边存在__<a href="https://dengxiaolong.com/caddy/cn-doc/http.rewrite.html" title="rewrite">rewrite</a>__指令，而caddy并没有处理两者之间的优先级导致的。<a href="https://www.bing.com/" title="bing">bing</a>搜索一下，发现果然有这方面的讨论。</p><p><a href="https://github.com/mholt/caddy/issues/1107">https://github.com/mholt/caddy/issues/1107</a></p><p>其中，hlidotbe提到：</p><blockquote>Looking a bit further, I see why it happens. in caddyhttp/httpserver/plugin.go "redir" is after "header", way after "rewrite".</blockquote><p>主要说的是<code>redir</code>是在在<code>rewrite</code>后面执行的，也就是说，先执行了rewrite逻辑，然后再执行redir逻辑。</p><p>查看<a href="https://github.com/mholt/caddy/blob/master/caddyhttp/httpserver/plugin.go">源代码</a>，果然如此：</p><pre><code class="lang-go">// directives is the list of all directives known to exist for the
// http server type, including non-standard (3rd-party) directives.
// The ordering of this list is important.
var directives = []string{
// primitive actions that set up the fundamental vitals of each config
"root",
"index",
"bind",
"limits",
"timeouts",
"tls",
// services/utilities, or other directives that don't necessarily inject handlers
"startup", // TODO: Deprecate this directive
"shutdown", // TODO: Deprecate this directive
"on",
"supervisor", // github.com/lucaslorentz/caddy-supervisor
"request_id",
"realip", // github.com/captncraig/caddy-realip
"git", // github.com/abiosoft/caddy-git
// directives that add listener middleware to the stack
"proxyprotocol", // github.com/mastercactapus/caddy-proxyprotocol
// directives that add middleware to the stack
"locale", // github.com/simia-tech/caddy-locale
"log",
"cache", // github.com/nicolasazrak/caddy-cache
"rewrite",
"ext",
"minify", // github.com/hacdias/caddy-minify
"gzip",
"header",
"geoip", // github.com/kodnaplakal/caddy-geoip
"errors",
"authz", // github.com/casbin/caddy-authz
"filter", // github.com/echocat/caddy-filter
"ipfilter", // github.com/pyed/ipfilter
"ratelimit", // github.com/xuqingfeng/caddy-rate-limit
"expires", // github.com/epicagency/caddy-expires
"forwardproxy", // github.com/caddyserver/forwardproxy
"basicauth",
"redir",
"status",</code></pre><p><a href="https://github.com/hlidotbe">hlidotbe</a> 还提到</p><blockquote><p>I think there's really only two (and a half) options:</p><p>1 merge redir and rewrite as most/all web servers do which makes the problem disappear and remove all ambiguity about it;<br>2 order rewrite after redir which may break some use cases but should limit surprises for most;<br>2.5 allow rewrite to redirect too but that would render redir redundant and often unused when rewrites are involved;</p></blockquote><p>简单翻译一下：<br>我认为最后解决方式只有2.5个选项：<br>1 像大多数web服务器软件一样（如nginx），合并<code>redir</code>和<code>rewrite</code>两个指令，让分歧彻底消失；<br>2 使<code>rewrite</code>指令在<code>redir</code>指定后面执行，这虽然会影响部分使用场景（有时候可能想重写后还能重定向），但会解决绝大部分疑惑；<br>2.5 允许<code>rewrite</code>指令支持重定向，不过这样就会让<code>redir</code>显得多余了。</p><p>既然，问题出现了，而且也没有解决方案，我们只能自己绕路而行了。<br>思路就是：</p><ul><li>rewrite命令想办法让需要redir的路径不重写；</li><li>其他一切不变</li></ul><p>最后，来看一下改进的Caddyfile文件：</p><pre><code class="lang-caddy"> # 先让rewrite过滤掉需要redir的路径
rewrite {
if {path} not /article/223672015323021312
if {path} not /article/2017/06/5.html
to {path} {path}/ /
}
# 先执行rewrite，再执行redir
redir 301 {
/article/223672015323021312 /article/2017/06/php-git-http-server.html
/article/2017/06/5.html /article/2017/06/php-git-http-server.html
}</code></pre><p>经过这样调整，caddy终于能正常相应redir的请求了。虽然这样来看，比nginx的<code>rewrite</code>配置要复杂不少，但其他地方的配置，尤其是https的配置，实在是要高明得多。对于普通的blog来说，caddy还是显得要便捷得多。</p>