细述HTTP 规范中的那些 “阴间”坑

小灰灰 2022-12-28 15:26 206阅读 0赞

![format_png][]

HTTP 协议可以说是开发者最熟悉的一个网络协议，「简单易懂」和「易于扩展」两个特点让它成为应用最广泛的应用层协议。

虽然有诸多的优点，但是在协议定义时因为诸多的博弈和限制，还是隐藏了不少暗坑，让人一不小心就会陷入其中。**本文总结了 HTTP 规范中常见的几个暗坑**，希望大家开发中有意识的规避它们，提升开发体验。

## 1.`Referer` ##

HTTP 标准把  `Referrer` 写成 `Referer`（少些了一个 `r`），可以说是计算机历史上最著名的一个错别字了。

`Referer` 的主要作用是**携带当前请求的来源地址，常用在反爬虫和防盗链上**。前段时间闹的沸沸扬扬的新浪图床挂图事件，就是因为新浪图床突然开始检查 HTTP `Referer` 头，非新浪域名就不返回图片，导致很多蹭流量的中小博客图都挂了。

虽然 HTTP 标准里把 `Referer` 写错了，但是其它可以控制 `Referer` 的标准并没有将错就错。

例如禁止网页自动携带 `Referer` 头的 **<meta>** 标签，相关关键字拼写就是正确的：

<meta name="referrer" content="no-referrer" />

还有一个值得注意的是浏览器的网络请求。

从安全性和稳定性上考虑，`Referer` 等请求头在网络请求时，只能由浏览器控制，不能直接操作，我们只能通过一些属性进行控制。比如说 **Fetch 函数**，我们可以通过 `referrer` 和 **`referrerPolicy`** 控制，而它们的拼写也是正确的：

fetch('/page', {
      headers: {
        "Content-Type": "text/plain;charset=UTF-8"
      },
      referrer: "https://demo.com/anotherpage", // <-
      referrerPolicy: "no-referrer-when-downgrade", // <-
    });

### 一句话总结： ###

凡是涉及到 Referrer 的，除了 HTTP 字段是错的，浏览器的相关配置字段拼写都是正确的。

## 二.「灵异」的空格 ##

### 1.`%20` 还是 `+` ？ ###

这个是个**史诗级的大坑**，我曾经被这个协议冲突坑了一天。

开始讲解前先看个小测试，在浏览器里输入 `blank test`（ `blank` 和 `test` 间有个空格），我们看看浏览器如何处理的：

![format_png 1][]

从动图可以看出浏览器把空格解析为一个加号「+」。

是不是感觉有些奇怪？我们再做个测试，用浏览器提供的几个函数试一下：

encodeURIComponent("blank test") // "blank%20test"
    encodeURI("q=blank test")        // "q=blank%20test"
    new URLSearchParams("q=blank test").toString() // "q=blank+test"

![format_png 2][] 浏览器编码规则

代码是不会说谎的，其实**上面的结果都是正确的**，encode 结果不一样，是因为 **URI 规范\[1\]和 W3C 规范\[2\]冲突了**，才会搞出这种让人疑惑的乌龙事件。

### 2.冲突的协议 ###

我们首先看看 URI 中的保留字\[3\]，这些保留字不参与编码。保留字符一共有两大类：

*  gen-delims：`:` `/` `?` `#` `[` `]` `@`
 *  sub-delims：`!` `$` `&` `'` `(` `)` `*` `+` `,` `;` `=`

URI 的编码规则也很简单，先把非限定范围的字符转为 16 进制，然后前面加百分号。

空格这种不安全字符转为十六进制就是 0x20，前面再加上百分号 `%` 就是 `%20`：

![format_png 3][]

所以这时候再看 `encodeURIComponent` 和 `encodeURI` 的编码结果，就是完全正确的。

既然空格转为`%20` 是正确的，那转为 `+` 是怎么回事？这时候我们就要了解一下 HTML form 表单的历史。

早期的网页没有 AJAX 的时候，提交数据都是通过 HTML 的 form 表单。form 表单的提交方法可以用 GET 也可以用 POST，大家可以在 MDN form 词条\[4\]上测试：

![format_png 4][]

经过测试我们可以看出**表单提交的内容中，空格都是转为加号的**，这种编码类型就是 `application/x-www-form-urlencoded`，在 WHATWG 规范\[5\]里是这样定义的：

![format_png 5][]

到这里基本上就破案了，`URLSearchParams` 做 encode 的时候，就按这个规范来的。我找到了 `URLSearchParams` 的 Polyfill 代码\[6\]，里面就做了 `%20` 到  `+` 的映射：

replace = {
        '!': '%21',
        "'": '%27',
        '(': '%28',
        ')': '%29',
        '~': '%7E',
        '%20': '+', // <= 就是这个
        '%00': '\x00'
    }

规范里对这个编码类型还有解释说明：

> *The* `application/x-www-form-urlencoded` format is in many ways an aberrant monstrosity, the result of many years of implementation accidents and compromises leading to a set of requirements necessary for interoperability, **but in no way representing good design practices**. In particular, readers are cautioned to pay close attention to the twisted details involving repeated (and in some cases nested) conversions between character encodings and byte sequences. **Unfortunately the format is in widespread use due to the prevalence of HTML forms**.
> 
>   
> 
> 
> 这种编码方式就不是个好的设计，不幸的是随着 HTML form 表单的普及，这种格式已经推广开了

其实上面一大段句话就是一个意思：**这玩意儿设计的就是 ????，但积重难返，大家还是忍一下吧**

### 3.一句话总结 ###

*  URI 规范里，空格 encode 为 `%20`， `application/x-www-form-urlencoded` 格式里，空格 encode 为 `+`
 *  实际业务开发时，最好使用业内成熟的 HTTP 请求库封装请求，这些杂活儿累活儿框架都干了；
 *  如果非要使用原生 AJAX 提交 `application/x-www-form-urlencoded` 格式的数据，不要手动拼接参数，要用 `URLSearchParams` 处理数据，这样可以避免各种恶心的编码冲突。

## 三.`X-Forwarded-For` 拿到的就是真实 IP 吗？ ##

### 1.故事 ###

在这个小节开始前，我先讲一个开发中的小故事，可以加深一下大家对这个字段的理解。

前段时间要做一个和风控相关的需求，需要拿到用户的 IP，开发后灰度了一小部分用户，测试发现后台日志里灰度的用户 IP **全是**异常的，哪有这么巧的事情。随后测试发过来几个异常 IP：

10.148.2.122
    10.135.2.38
    10.149.12.33
    ...

一看 IP 特征我就明白了，这几个 IP 都是 10 开头的，属于 A 类 IP 的私有 IP 范围（10.0.0.0-10.255.255.255），后端拿到的肯定是代理服务器的 IP，而不是用户的真实 IP。

### 2.原理 ###

![format_png 6][]

现在有些规模的网站基本都不是单点 Server 了，为了应对更高的流量和更灵活的架构，**应用服务一般都是隐藏在代理服务器之后的**，比如说 Nginx。

加入接入层后，我们就能比较容易的实现多台服务器的负载均衡和服务升级，当然还有其他的好处，比如说更好的内容缓存和安全防护，不过这些不是本文的重点就不展开了。

网站加入代理服务器后，除了上面的几个优点，同时引入了一些新的问题。比如说之前的单点 Server，服务器是可以直接拿到用户的 IP 的，加入代理层后，如上图所示，（应用）原始服务器拿到的是代理服务器的 IP，我前面讲的故事的问题就出在这里。

Web 开发这么成熟的领域，肯定是有现成的解决办法的，那就是  X-Forwarded-For\[7\] 请求头。

`X-Forwarded-For` 是一个事实标准，虽然没有写入 HTTP RFC 规范里，从普及程度上看其实可以算 HTTP 规范了。

这个标准是这样定义的，每次**代理服务器转发请求到下一个服务器时**，要把代理服务器的 IP 写入 `X-Forwarded-For` 中，这样在最末端的应用服务收到请求时，就会得到一个 IP 列表：

X-Forwarded-For: client, proxy1, proxy2

因为 IP 是一个一个依次 push 进去的，那么第一个 IP 就是用户的真实 IP，取来用就好了。

**但是，事实有这么简单吗？**

### 3.攻击 ###

从安全的角度上考虑，整个系统最不安全的就是人，用户端都是最好攻破最好伪造的。有些用户就开始钻协议的漏洞：`X-Forwarded-For` 是代理服务器添加的，如果我一开始请求的 Header 头里就加了 `X-Forwarded-For` ，不就骗过服务器了吗？

**1.** 首先从客户端发出请求，带有 `X-Forwarded-For` 请求头，里面写一个伪造的 IP：

X-Forwarded-For: fakeIP

**2.** 服务端第一层代理服务收到请求，发现已经有 `X-Forwarded-For`，误把这个请求当成代理服务器，于是向这个字段追加了客户端的真实 IP：

X-Forwarded-For: fakeIP, client

**3.** 经过几层代理后，最终的服务器拿到的 Header 是这样的：

X-Forwarded-For: fakeIP, client, proxy1, proxy2

要是按照取 `X-Forwarded-For` 第一个 IP 的思路，你就着了攻击者的道了，你拿到的是 fakeIP，而不是 client IP。

### 4.破招 ###

服务端如何破招？上面三个步骤：

*  第一步是客户端造假，服务器无法介入
 *  第二步是代理服务器，可控，可防范
 *  第三步是应用服务器，可控，可防范

第二步的破解我拿 Nginx 服务器举例。

我们在最外层的 Nginx 上，对 `X-Forwarded-For` 的配置如下：

proxy_set_header X-Forwarded-For $remote_addr;

什么意思呢？就是**最外层代理服务器不信任客户端的 `X-Forwarded-For` 输入，直接覆盖，而不是追加**。

非最外层的 Nginx 服务器，我们配置：

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

`$proxy_add_x_forwarded_for` 就是追加 IP 的意思。通过这招，就可以破解用户端的伪造办法。

第三步的破解思路也很容易，正常思路我们是取`X-Forwarded-For` 最左侧的 IP，这次我们反其道而行之，**从右边数，减去代理服务器的数目**，那么剩下的 IP 里，最右边的就是真实 IP。

X-Forwarded-For: fakeIP, client, proxy1, proxy2

比如说我们已知代理服务有两层，从右向左数，把 `proxy1` 和 `proxy2` 去掉，剩下的 IP 列表最右边的就是真实 IP。

相关思路和代码实现可参考 Egg.js 前置代理模式\[8\]。

### 5.一句话总结总结 ###

通过 `X-Forwarded-For` 获取用户真实 IP 时，最好不要取第一个 IP，以防止用户伪造 IP。

## 四.略显混乱的分隔符 ##

### 1.HTTP 标准 ###

HTTP 请求头字段如果涉及到多个 value 时，一般来说**每个 value 间是用逗号「,」分隔的**，就连非 RFC 标准的 `X-Forwarded-For`，也是用逗号分隔 value 的：

Accept-Encoding: gzip, deflate, br
    cache-control: public, max-age=604800, s-maxage=43200
    X-Forwarded-For: fakeIP, client, proxy1, proxy2

因为一开始用逗号分隔 value，后面想再用一个字段修饰 value 时，分隔符就变成了分号「;」，最典型的请求头就是 `Accept` 了：

//  q=0.9 修饰的是 application/xml，虽然它们之间用分号分隔
    Accept: text/html, application/xml;q=0.9, */*;q=0.8

虽然 HTTP 协议易于阅读，但是这个分隔符用的还是很不符合常识的。**按常理来说，分号的断句语气是强于逗号的**，但是在 HTTP 内容协商的相关字段里却是反过来的。这里的定义可以看 RFC 7231\[9\]，写的还是比较清楚的。

### 2.Cookie 标准 ###

和常规认识不同，Cookie 其实不算 HTTP 标准，定义 Cookie 的规范是 RFC 6265\[10\]，所以分隔符规则也不一样了。规范里定义的 Cookie 语法规则\[11\]是这样的：

cookie-header = "Cookie:" OWS cookie-string OWS
    cookie-string = cookie-pair *( ";" SP cookie-pair )

**多个 cookie 之间是用分号「;」分隔的**，而不是逗号「,」。我随便扒了个网站的 cookie，可见是用分号分隔的，这里需要特别注意一下：

![format_png 7][]

### 3.一句话总结 ###

*  大部分 HTTP 字段的 value 分隔符是逗号「,」
 *  Cookie 不属于 HTTP 标准，分隔符是分号「;」

## 五、文章推荐 ##

下面我要推荐我的几篇文章：

*  一篇介绍了 webpack 中最易混淆的 5 个知识点\[12\]，掘金快 800 赞了，一文讲清楚 Webpack 中那些**长得像却意义不同的概念**
 *  一篇详细介绍了 webpack dll 是个什么东西\[13\]，并且给出了 2 条最佳实践，**摆脱繁琐的 dll 配置**
 *  React Native 性能优化指南\[14\]从渲染层的角度分析了 RN 性能优化的 6 个点，并以图文形式讲解了 FlatList 的实现原理
 *  [Web Scraper——轻量数据爬取利器][Web Scraper] 介绍了一个小巧的浏览器爬虫插件，可以实现简单的数据爬取功能

--------------------

### 参考资料 ###

\[1\]

URI 规范: *https://tools.ietf.org/html/rfc3986*

\[2\]

W3C 规范: *https://www.w3.org/TR/html4/interact/forms.html\#h-17.13.4.1*

\[3\]

保留字: *https://tools.ietf.org/html/rfc3986\#p-2.2*

\[4\]

MDN form 词条: *https://developer.mozilla.org/zh-CN/docs/Web/HTML/Element/form*

\[5\]

WHATWG 规范: *https://url.spec.whatwg.org/\#urlencoded-serializing*

\[6\]

Polyfill 代码: *https://github.com/WebReflection/url-search-params/blob/814161e99f1dd4453f3c1dc594bc73da2bd61838/build/url-search-params.node.js\#L88*

\[7\]

X-Forwarded-For: *https://en.wikipedia.org/wiki/X-Forwarded-For*

\[8\]

Egg.js 前置代理模式: *https://eggjs.org/zh-cn/tutorials/proxy.html*

\[9\]

RFC 7231: *https://tools.ietf.org/html/rfc7231*

\[10\]

RFC 6265: *https://tools.ietf.org/html/rfc6265*

\[11\]

Cookie 语法规则: *https://tools.ietf.org/html/rfc6265\#p-4.2.1*

\[12\]

webpack 中最易混淆的 5 个知识点: *https://juejin.im/post/5cede821f265da1bbd4b5630*

\[13\]

webpack dll 是个什么东西: *https://juejin.im/post/5d8aac8fe51d4578477a6699*

\[14\]

React Native 性能优化指南: *https://juejin.im/post/5e1676e16fb9a04847095b12*

## ❤️看完三件事 ##

如果你觉得这篇内容对你挺有启发，我想邀请你帮我三个小忙：

1.  点赞，让更多的人也能看到介绍内容（收藏不点赞，都是耍流氓-\_-）
2.  关注公众号“前端劝退师”，不定期分享原创知识。
3.  也看看其他文章

![format_png 8][]

劝退师个人微信：**huab119**

也可以来我的`GitHub`博客里拿所有文章的源文件：

**前端劝退指南**：https：//github.com/roger-hiro/BlogFN一起玩耍呀

点赞、在看 支持作者❤️

[format_png]: /images/20221120/63b271ede6c34a5198b0b575e096103e.png
[format_png 1]: /images/20221120/cbc110ea99f149c9bf3dd3644fd00cac.png
[format_png 2]: /images/20221120/a6f3e0e0a8194e5583c4bd5521a555f3.png
[format_png 3]: /images/20221120/832677d538364f4ca3f29e0de140f3db.png
[format_png 4]: /images/20221120/bb12859d8dba412c8c1a6ba60ac36b52.png
[format_png 5]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X3BuZy84TUs4WDJYUWd1N0FReXc1ajJDNWxFVHBEaWF3SjF1U3FhZHZpYkt1RmNGejJ2TFpFZWpIZWhpY1A2NVE4anJzSEhXZ3RPQUszQzlMWHM4UkNRRzdiR1M4US82NDA?x-oss-process=image/format,png
[format_png 6]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X3BuZy84TUs4WDJYUWd1N0FReXc1ajJDNWxFVHBEaWF3SjF1U3F1dTFHd3VDT2h2ZkFNajdBdEJLUGFzN0ZHYU9DS3BwZjVyZlZ0ME4yaFlNSWs1aWNVMGliTHBQUS82NDA?x-oss-process=image/format,png
[format_png 7]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X3BuZy84TUs4WDJYUWd1N0FReXc1ajJDNWxFVHBEaWF3SjF1U3E5bkppYjZpYVFYODNYTXZYUXM2dWQ0bUh1VE4zR3ZMamR4SkVkOXdTeDZKQnpIZm5qRDVET1BMUS82NDA?x-oss-process=image/format,png
[Web Scraper]: https://mp.weixin.qq.com/s?__biz=MzI4OTU0NTU1NA%3D%3D&idx=1&mid=2247484536&scene=21&sn=dd3bb2aaeee0425c0d697f7edcba279f#wechat_redirect
[format_png 8]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X2pwZy9pY25yTkJpY0Voa1ZXMWNCOUdLTFI3OUFaN3BXY1JDSnNoR0p3dDRpY0RiUjBxbnphSkJZenJRc053UGVoRHpMRmxjVEdpYnhsQWdVTGhIQ0pPQzN5RHBaQVEvNjQw?x-oss-process=image/format,png