熟悉 CDN 行业主流技术的朋友应该都比较清楚，虽然 Nginx 近几年发展的如日中天，但是基本上没有直接使用它自带的 proxy_cache 模块来做缓存的，原因有很多，例如下面几个：

• 不支持多盘
• 不支持裸设备
  
• 大文件不会切片
  
• 大文件的 Range 请求表现不尽如人意
  
• Nginx 自身不支持合并回源
  
  

有时候，仔细追踪一个项目的各次提交也是蛮有趣的，特别是各种 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.

再来看看是如何修复的，变更前的代码片段:

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 头部（请求头、响应头）主要包括如下两方面的作用：
1. 控制不再转发给代理的首部字段 2. 管理持久连接

其中，我个人经常见到的是第二种用法，对第一种用法还不甚了解。

第一种用法，大概意思就是，在一个 HTTP 应用（客户端、服务器）将报文转发出之前，必须删除 Connection 首部列出的所有首部字段（多个不同的字段用逗号分隔），当然一些 end-to-end 的头部是肯定不能放进去的，例如 Cache-Control 头。

2015年12月6日，我的第二次半程马拉松之旅结束了。觉得应该记录一下，但跑完了却又没什么特别想说的了，就说几个点权当流水账吧。

关于天气，用天公作美来形容再贴切不过了。广州经过多次试探，终于找到了入冬的节奏，气温骤降，还有阵阵小雨。本来以为这次会像三月份的清远马拉松一样冒雨奔跑，还在担心这寒冷的天气淋雨可能会吃不消，结果当天突然风和日丽，蓝天白云。真是一个惊喜。

这次半马，我的准备工作其实是不足的。最近已经有两周没有跑步了，而且当天早上还没有任何进食，直接空腹开跑，但还好之前还是积累了一定的跑量，再加上之前已经有一次半马的经验了，所以心理上并没有什么压力。

毕业工作后，我其实一直都没有真正尝过挤公交车、地铁上班的滋味，因为我租的房子总在公司附近，况且还每天骑车上班。但是这种好景在今年九月份时结束了，新公司距离住的地方要坐一个小时的公交车。这几个月挤公交车的经历大概可以分为几个阶段。

1. 噩梦般的挤车体验

这个时期，我大概七点半起床，八点左右到达公交站，公交站里已经是人头攒动了。想挤上去绝对是个体力活。而且，大家似乎都有这么一种心理，当自己是往上挤的一方时，就希望车里的人往里面动一动，腾出点空间，可如果自己在里面站定了后，到了后面的站时，却又不愿意给后来人腾出地方了。这种情况就导致了车门口附近的区域变成噩梦一般的存在。

必须得想办法了。