我们密切关注提到CloudFlare的tweet，因为有时候我们会得到一些关于奇怪错误的早期警告，这些错误是我们无法通过监控系统看到的。在8月底，我们看到了一些类似这样的微博：表示尝试使用Twitter in-app浏览器浏览CloudFlare客户网站时出现错误页面。这很奇怪，因为它显然只是偶尔发生：非常偶然。幸运的是，发推特的人和我在同一时区，能够一起帮助调试（谢谢James White！）；我们发现以下事件序列是重现该bug所必需的：单击tweet中指向使用https URL并在Twitter应用内浏览器（而不是mobile Safari）中打开的网站的链接。此站点可能是也可能不是CloudFlare客户。然后单击该页面上通过http URL指向站点的链接。此站点必须位于CloudFlare上。繁荣这解释了为什么这种情况很少发生，但问题是。。。为什么会这样？经过一番调试，iOS和Twitter应用程序（包括iOS9测试版）的最新版本都出现了这种情况。为了弄清楚到底发生了什么，我求助于Charles Proxy，并用它拦截我的iPhone和CloudFlare之间的通信。幸运的是，Charles Proxy可以通过在电话上安装自定义证书来拦截SSL连接。我在我的笔记本电脑上运行Charles Proxy，将iPhone指向它（将其用作代理），然后点击tweet链接到我专门为测试而设置的站点。Charles Proxy显示生成错误的请求如下所示：获取/测试HTTP/1.1\r\n主持人：网站\r\n引用者：\r\n接受编码：gzip，deflate\r\n接受：text/html，application/xhtml+xml，application/xml；q=0.9，*/*；q=0.8\r\n接受语言：en-us\r\n连接：保持活动\r\n用户代理：Mozilla/5.0（iPhone；CPU iPhone OS 8_4_1类似Mac OS X）AppleWebKit/600.1.4（KHTML，如Gecko）Mobile/12H321 Twitter for iPhone\r\n\r\n乍一看，这看起来很正常，但再看一眼，有些东西真的很突出：引用者：\r\nRFC7231明确指出，如果Referer头存在，它必须包含一个URI："Referer"[sic]头字段允许用户代理指定从中获取目标URI的资源的URI引用（即"referer"，尽管字段名称拼写错误）。用户代理不能包含生成Referer字段时，如果有URI引用[RFC3986]价值观。Referer=绝对URI/部分URIRFC还提供了一个线索，说明为什么从HTTPS跳到HTTP时头处于这种状态：用户代理不能在如果使用安全协议。CloudFlare的浏览器完整性检查是验证Referer头的格式是否正确，并生成错误（因为有Referer，但它是空的），看起来Twitter app-in-app-Browser（以及我们后来发现的Facebook-app-in-app-Browser）并没有删除头，而是将其清空。这是一个很好的例子，说明"严格"地遵守RFC并不总是容易的。波斯特定律告诉我们，在这种情况下，CloudFlare需要放松检查。我们向Twitter和Facebook报告了这个问题，并推出了一个修复程序，允许这些客户端出现这种行为，并在有意义时重新启用严格的检查。但是如果你验证了Referer头，请注意你的软件。你可能会碰到这种怪事。