继续留在 Typecho
最近手心手背总时不时发痒,又开始想折腾博客玩了。
这个小小的个人博客,从 2011 年开始,几乎把主流的 Blog 系统折腾了个遍,从最初的 Wordpress,到 Typecho、Emlog、Textpattern 等等。其中,Typecho 被来回折腾了几次,因为 Typecho 自身也经历了两个大的阶段:从几年没有维护,到开始重构并默认支持 Markdown 编辑器。
每个阶段维护博客的心态也不一样。刚开始的时候,总到处想和人交换链接,把界面搞得好看点,各种插件都试一试。这个阶段确实还真认识了一些一起写博客的同学,大家经常互访互评,搞得还挺热闹。但是必须要知道的是,即使在 2011 年之前,个人博客也早已经开始没落了,这是大势所趋,曾经的那些博客,到现在也已经绝大多数打不开,还挺让人唏嘘的。
尝鲜:Nginx-1.9.8 推出的切片模块
熟悉 CDN 行业主流技术的朋友应该都比较清楚,虽然 Nginx 近几年发展的如日中天,但是基本上没有直接使用它自带的 proxy_cache 模块来做缓存的,原因有很多,例如下面几个:
- 性能不好(相对于 ATS 等专业的 cache 软件)
- 不支持裸设备
- 大文件不会切片
- 大文件的 Range 请求表现不尽如人意
- Nginx 自身不支持合并回源
Nginx 紧急发布 1.9.9 修复 bug
有时候,仔细追踪一个项目的各次提交也是蛮有趣的,特别是各种 Bugfix,会发现,原来牛人也会有各种低级错误。
例如,Nginx 刚在 12 月 8 号发布了 nginx-1.9.8,马上就又发布 nginx-1.9.9,这种密集的发布,一看就是 Bug 修复了。我们看看到底修复了什么 Bug。
首先,看看changelog:
Changes with nginx 1.9.9 09 Dec 2015
*) Bugfix: proxying to unix domain sockets did not work when using variables; the bug had appeared in 1.9.8.
再来看看是如何修复的,变更前的代码片段:
Nginx 对 Connection 头的处理过程
1. 标准
RFC2616 中,对 Connection 的说明如下:
HTTP/1.1 proxies MUST parse the Connection header field before a message is forwarded and, for each connection-token in this field, remove any header field(s) from the message with the same name as the connection-token. Connection options are signaled by the presence of a connection-token in the Connection header field, not by any corresponding additional header field(s), since the additional header field may not be sent if there are no parameters associated with that connection option.
综合 RFC2626 14.10、《HTTP权威指南》4.3.1、《图解HTTP》6.3.2中的说法,均指明了 Connection 头部(请求头、响应头)主要包括如下两方面的作用:
- 控制不再转发给代理的首部字段
- 管理持久连接
其中,我个人经常见到的是第二种用法,对第一种用法还不甚了解。
第一种用法,大概意思就是,在一个 HTTP 应用(客户端、服务器)将报文转发出之前,必须删除 Connection 首部列出的所有首部字段(多个不同的字段用逗号分隔),当然一些 end-to-end 的头部是肯定不能放进去的,例如 Cache-Control 头。