标签 caddy 下的文章

一直以为，抓取网站整站，要么需要一个非常牛的工具，要么自己用curl之类写一个。这次想把caddy的英文文档的站点做个镜像的时候，竟然发现可以直接利用wget来实现，还真是小瞧了这个常见的工具了。

wget的参数的详解，网上已经很多了，就不再copy了，有兴趣详细了解的朋友可以参考下面的链接：

首先，我想做caddy的doc的镜像的原因是因为经常访问不了，也就是说，不想通过代理才能访问，所以，我需要使用代理的相关命令。因为caddy是https协议，所以我export一个变量https_proxy来作为代理。

- 阅读剩余部分 -

网站讲究高可用，讲究不间断服务。而对于刚接触caddy的我们而言，修改配置文件是加家常便饭，比如：增加日志监控，增加一个301重定向什么的。那么修改了配置文件，配置文件是否配置正确呢？配置后又该怎么重启呢？如何确保重启过程的不间断服务呢？如果出现服务挂掉该怎么确保服务的自动启动呢？这一系列的疑问，我们今天来一一释怀吧。但是，需要相信的是，caddy作为一个新生代的web服务器软件，这些方面肯定会考虑到的。本文将参考官方的命令行模式文档，为这些问题一一解答。

ps.关于Caddy的命令行参数，也可以参考我翻译的中文文档：Caddy命令行参数

如何检查配置文件正确性

caddy指定配置文件的参数是-conf，那么怎么验证配置文件是否正确呢？就像nginx的-t参数一样，caddy有-validate参数可供使用。看一下官方文档：

-validate
Parse the Caddyfile and exit. If syntactically valid, a message will be printed to stdout and the process log (if any) and will exit with status 0. If not, an error will be returned with a non-zero exit status.

解析Caddyfile并退出，如果句法结构正确，将会通过标准输出打印一条信息，记录日志（如果配置了），最后会退出，退出码为0。否则，会报出相应的错误信息，状态码为非0。

- 阅读剩余部分 -

网站改版后，很难确保新的网址和旧的网址保持一致，因此总需要写一些重定向规则，确保原来被搜索引擎抓取的页面能重定向到新的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
&quot;root&quot;,
&quot;index&quot;,
&quot;bind&quot;,
&quot;limits&quot;,
&quot;timeouts&quot;,
&quot;tls&quot;,

// services/utilities, or other directives that don&#039;t necessarily inject handlers
&quot;startup&quot;,  // TODO: Deprecate this directive
&quot;shutdown&quot;, // TODO: Deprecate this directive
&quot;on&quot;,
&quot;supervisor&quot;, // github.com/lucaslorentz/caddy-supervisor
&quot;request_id&quot;,
&quot;realip&quot;, // github.com/captncraig/caddy-realip
&quot;git&quot;,    // github.com/abiosoft/caddy-git

// directives that add listener middleware to the stack
&quot;proxyprotocol&quot;, // github.com/mastercactapus/caddy-proxyprotocol

// directives that add middleware to the stack
&quot;locale&quot;, // github.com/simia-tech/caddy-locale
&quot;log&quot;,
&quot;cache&quot;, // github.com/nicolasazrak/caddy-cache
&quot;rewrite&quot;,
&quot;ext&quot;,
&quot;minify&quot;, // github.com/hacdias/caddy-minify
&quot;gzip&quot;,
&quot;header&quot;,
&quot;geoip&quot;, // github.com/kodnaplakal/caddy-geoip
&quot;errors&quot;,
&quot;authz&quot;,        // github.com/casbin/caddy-authz
&quot;filter&quot;,       // github.com/echocat/caddy-filter
&quot;ipfilter&quot;,     // github.com/pyed/ipfilter
&quot;ratelimit&quot;,    // github.com/xuqingfeng/caddy-rate-limit
&quot;expires&quot;,      // github.com/epicagency/caddy-expires
&quot;forwardproxy&quot;, // github.com/caddyserver/forwardproxy
&quot;basicauth&quot;,
&quot;redir&quot;,
&quot;status&quot;,</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>

- 阅读剩余部分 -