何时从http请求规范中使用absoluteUri？

Question

我一直在研究具有getRequestURI和getRequestURL方法的HttpServletRequest API（Java）。这让我看看：https://tools.ietf.org/html/rfc7230#section-5.3据我所知，getRequestURI返回http请求第一行的值，这是大多数时候资源的相对路径，除非源服务器在入站代理后面，在这种情况下它必须是绝对URI。我想互联网上流行网站的大多数原始服务器属于该类别，这意味着原始http请求中的URI应该是absoluteUri（来自http规范），但我还没有设法在任何地方找到这样的例子。浏览器是否真的知道它是将其请求发送到入站代理还是直接发送到源服务器？ http规范中的absoluteUri概念是否有任何实用价值？因为Host头字段始终在HTTP 1.1请求中发送。当没有Host头字段时，规范的那一部分在HTTP 1.0时具有一些实用价值吗？

Answer 1

我想你可能会对正在讨论的代理类型感到困惑。看起来RFC指的是一个转发代理，您通过另一个服务器向另一个服务器发出请求（客户端告诉代理将流量转发到哪里）。

使用反向代理，您是对的，客户端不知道请求已被代理到另一台服务器。

Difference between proxy server and reverse proxy server

Answer 2

来自http协议1.0规范

只有在向代理发出请求时，才允许使用absoluteURI表单。请求代理转发请求并返回响应。如果请求是GET或HEAD并且先前的响应被缓存，则代理可以使用缓存的消息，如果它在Expires头字段中传递任何限制。请注意，代理可以将请求转发到另一个代理或直接转发到absoluteURI指定的服务器。为了避免请求循环，代理必须能够识别其所有服务器名称，包括任何别名，本地变体和数字IP地址。 Request-Line的示例是：GET /TheProject.html HTTP/1.0

Request-URI的最常见形式是用于标识源服务器或网关上的资源。在这种情况下，只传输URI的绝对路径(see Section 3.2.1, abs_path)。例如，希望直接从源服务器检索上述资源的客户端将创建到主机“www.w3.org”的端口80的TCP连接，并发送以下行：GET /pub/WWW/TheProject.html HTTP / 1.0后面是Full-Request的剩余部分。注意绝对路径不能为空;如果原始URI中不存在，则必须将其指定为“/”（服务器根目录）。

所以这是有一个实际的意义，但只有当你知道你实际上发布到代理。浏览器实际上并不知道他正在向代理提交信息，但由于这是最常见的情况，这就是为什么你总是传输主机和uri属性而不是显式路径。现代（而不是那么现代）代理从主机，协议，端口和URI重构URL

以下面的例子为例

GET /standards/ HTTP/1.1
Host: www.w3.org
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://www.w3.org/
Connection: keep-alive
Upgrade-Insecure-Requests: 1

代理将重建客户端用于发出请求的URL。返回的URL将包含协议，服务器名称，端口号和服务器路径。

在java omething类似的事情。如果你看看servletapi specs，你也会看到同样的行为。

因此，根据经验，只有在向代理发出请求时才允许使用absoluteURI表单。请求不一定来自浏览器，但是如果代理没有收到绝对路径，它会使用标头中的其余数据构造URL，类似于java的getURL。

Answer 3

好的丹尼尔斯科特已经确定了我最初混淆的根源。我将记下一些对我来说不太清楚的观点，并阻止我正确理解规范：

1. 前向代理通常简称为“代理”。
2. 反向代理通常被称为“网关”。
3. 出于某种原因，我认为转发代理与出站代理同义，反向代理与入站代理同义。我想我已经在一些关于代理的文章中看到了它，但我不知道这些术语是否被广泛使用。
4. 在我们位于转发代理后面的TCP / IP级别上，所有Web流量都将发送到该代理。浏览器从不直接与源服务器通信，并且必须以某种方式将地址（IP或域名）发送到转发代理，以便它可以代表客户端与源服务器通信。这发生在请求行中的HTTP协议级别。当我们不在前向代理后面时，我们可以直接通过TCP / IP与源服务器通信，并且不需要HTTP级别Request-Line中的绝对URL。
5. 请求行中的绝对URL是从HTTP / 1.0时开始设计的，用于处理前向代理后面的通信问题。主机头字段被HTTP / 1.1规范引入为强制标头，由此引入了对虚拟主机的支持。我想HTTP / 1.1可能只是简单地使绝对URL成为必需的并且一石二鸟但是由于某种原因它决定主机头解决方案更好。
6. 我意识到除了正向和反向代理之外，还有“透明”代理。这些是ISP和诸如此类使用的CDN或代理。它们既不是前向也不是反向，并且不需要两个通信方都不需要配置。他们与这个问题没有任何关系，但这曾经让我感到困惑。

另外我想说我做了一个实验，证实了http规范中的内容。

我用谷歌搜索“免费代理IP和端口”，转到“https://www.hide-my-ip.com/proxylist.shtml”并配置窗口使用转发代理（控制面板 - > Internet选项 - >连接 - > Lan设置 - >“使用代理服务器...”）。然后我向www.bbc.com提出了请求，并检查了Chrome控制台网络选项卡中的原始http请求，请求行中的地址是绝对的。然后我删除了代理并再次提出了相同的请求。请求线上的地址现在只是路径。

我不确定Alexius Diakogiannos所提到的代理人对网址事物的全部重建。似乎非常符合逻辑，如果客户端不发送绝对URL，这是大多数前向代理所具有的选项，但是从我所看到的，至少chrome，当它意识到它在它后面时，正确地将绝对URL发送到代理。当然，我自己从未管理/运行过转发代理，所以我不知道。