为什么HTTP请求行中会出现“https”?

问题

HTTP明明是跑在TLS之上,怎么会意识到https的存在呢?


太长不看

在HTTP/1.1给正向代理的请求行中,方法后面的参数是 absoluteURI ,而非 http URL,即可以使用任何代理支持的协议。 也就是说,该参数表达的是任何可以识别特定资源的标志,所以https作为一种协议可能会出现在该位置。


文档规定

RFC2616 中,规定请求行的格式为 Method SP **Request-URI** SP HTTP-Version CRLF ,而 Request-URI 的格式为 "*" | absoluteURI | abs_path | authority 。其中,abs_path 是我们最常看到的,例如 /pub/WWW/TheProject.html,通过联合请求头中的HOST字段,我们就可以访问到资源了。


但有时我们的HTTP请求是给一个正向代理的。HTTP/1.1规定,在这种情况下,Request-URI 必须 absoluteURI 的格式,即 scheme ":" ( hier_part | opaque_part ) 。其中,scheme 定义了该URI的命名空间,告诉了代理该资源标识符的语义和语法。所以,它可以是 https:// … 或者 ftp:// … ,甚至可以不指定协议,例如 file:// …


同时,为了避免在代理的过程中产生回环, RFC2616 要求代理的实现必须能够通过 absoluteURI 确定资源所有的服务器/别名,IP地址,主机名等。


设计分析

为什么给正向代理的HTTP请求行中需要URI,而非 abs_path + HOST字段?

因为这里只确定客户端和代理之间是通过HTTP协议通信的,并不知道代理会通过何种方式访问资源。所以我们需要在HTTP请求行中告知代理URI,如果代理支持对应的访问,则在成功获取资源后通过HTTP返回给客户端。

另外,除了直接请求资源服务器,代理也可能把这个请求交给下一个代理,这之间的通信也可能不是基于HTTP的,只有代理在知道完整URI的情况下才能确保接下来的步骤正确运行。


如果使用绝对URI,是否会和HOST字段的信息产生冗余?

在HTTP/1.1中,HOST字段是强制的。其目的是告知服务端请求资源所在的(虚拟)主机和端口号,例如 Host: www.w3.org 所以代理请求行中的绝对URI是会和HOST产生信息冗余的。事实上,RFC7230 规定这种情况下代理必须忽略HOST字段信息,并通过请求行中的URI重新填充HOST字段。


为什么实现不良的代理可能会产生回环?

在现在的网络环境下,CDN/反向代理的情况非常普遍。CDN的边际网络会根据请求选择直接返回缓存或者继续转发请求,所以一个请求可能会被多次代理。但是,如果代理无法、或错误的判断资源来源时,就可能发生回环。例如,代理 A 判断应该把请求交给代理B,但是 B 在接到请求后认为该请求应该交给代理 A ,这样就形成了回环(也可能有多个节点),最终导致请求被丢弃。

如上图所示,这种回环的发生不仅导致了数据的丢失,也耗费了大量带宽和代理的资源。事实上,这也被作为一种对CDN的“杠杆”拒绝服务攻击


关于如何通过扩展HTTP头来解决这个问题,可以参考 Preventing Request Loops Using CDN-Loop


后记

回到最初的问题,如上所述,代理对于不同 scheme 的支持完全取决于实现,如果代理无法支持以 https:// 开头的代理请求,则会返回4xx状态。例如 CDN 提供商 fastly 在4年前就是这样


posted @ 2020-01-17 08:20  李秋豪  阅读(328)  评论(0编辑  收藏