我一直在研究具有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请求中发送。当没有主机头字段时,规范的那一部分在HTTP 1.0时具有一些实用价值吗?
答案 0 :(得分:2)
我认为您可能会对所讨论的代理类型感到困惑。看起来RFC指的是一个转发代理,你通过另一个服务器向另一个服务器发出请求(客户端告诉代理将流量转发到哪里)。
使用反向代理,您是对的,客户端不知道请求已被代理到另一台服务器。
答案 1 :(得分:1)
来自http协议1.0规范
只有在向代理发出请求时才允许使用absoluteURI表单。请求代理转发请求并返回响应。如果请求是GET或HEAD并且先前的响应被缓存,则代理可以使用缓存的消息,如果它在Expires头字段中传递任何限制。请注意,代理可以将请求转发到另一个代理或直接转发到absoluteURI指定的服务器。 为了避免请求循环,代理必须能够识别其所有服务器名称,包括任何别名,本地变体和数字IP地址。示例请求行将是:{{ 1}}
最常见的形式的Request-URI是用于识别a的 源服务器或网关上的资源。在这种情况下,只有 传输URI的绝对路径 (see Section 3.2.1, abs_path)。 例如,希望直接检索上述资源的客户端 从源服务器将创建到端口80的TCP连接 主持人“www.w3.org”并发送电话: 获取/pub/WWW/TheProject.html HTTP / 1.0,然后是完整请求的剩余部分。注意绝对路径不能为空;如果 原始URI中不存在,它必须以“/”( 服务器根目录。)
所以这是有实际意义的,但前提是你知道你实际上是在发布代理。浏览器实际上并不知道他正在向代理提交信息,但由于这是最常见的情况,这就是为什么你总是传输主机和uri属性而不是显式路径。现代(而不是那么现代)代理从主机,协议,端口和URI
重建URL以下面的例子为例
GET /TheProject.html HTTP/1.0
代理将重建客户端用于发出请求的URL。返回的URL将包含协议,服务器名称,端口号和服务器路径。
在java中,类似的东西已经完成了。如果您查看servletapi specs,您也会看到相同的行为。
因此,根据经验,只有在向代理发出请求时才允许使用absoluteURI表单。请求不一定来自浏览器,但是如果代理没有收到绝对路径,它会使用标头中的其余数据构造URL,类似于java的getURL。
答案 2 :(得分:1)
好的丹尼尔斯科特已经确定了我最初混淆的根源。我会记下一些对我来说不太清楚的观点,使我无法正确理解规范:
另外我想说我做了一个实验,证实了http规范中的内容。
我用谷歌搜索"免费代理ip和端口",去了" https://www.hide-my-ip.com/proxylist.shtml"并配置窗口以使用转发代理(控制面板 - > Internet选项 - >连接 - > Lan设置 - >"使用代理服务器......")。然后我向www.bbc.com提出了请求,并检查了Chrome控制台网络选项卡中的原始http请求,请求行中的地址是绝对的。然后我删除了代理并再次提出了相同的请求。请求线上的地址现在只是路径。
我不确定Alexius Diakogiannos所提到的代理人对url事物的整个重建。似乎非常符合逻辑,如果客户端不发送绝对URL,这是大多数前向代理所具有的选项,但是从我所看到的,至少chrome,当它意识到它在它后面时,正确地将绝对URL发送到代理。当然,我自己从未管理/运行过代理,所以我不知道。