没有端口的HTTP X转发主机行为 [英] HTTP X-Forwarded-Host Behavior Without Port

问题描述

我发现在端口的情况下，X-Forwarded-Host HTTP标头的定义不是很好.也许这就是为什么各种实现在此标头方面表现不同的原因.通常，此标头可以包含一个端口，例如b.com:123这很简单.但是，如果不包含端口并且服务器在非默认端口上运行，该怎么办?经过少量研究，我发现一些实现引入了非官方的" X-Forwarded-Port标头.

I found out that X-Forwarded-Host HTTP header is not very well defined in the case of ports. Maybe that is the reason why various implementations behave differently when it comes to this header. Usually, this header can contain a port, e.g. b.com:123 which is straightforward. But what if it does NOT contain a port and server is running on non-default port? After my little research, I discovered that some implementations introduce "non-official" X-Forwarded-Port header.

现在，我正在考虑在服务器上实施，我的想法是，如果X-Forwarded-Host标头不带端口，则输出URL也应该不也包含端口，即使服务器运行的端口与默认端口不同(如果不存在X-Forwarded-Port标头).

Right now, I'm thinking of implementation on the server and my thoughts are that if X-Forwarded-Host header is present without port, then output URLs should not contain a port as well even if the server is running on different than the default port (if X-Forwarded-Port header is not present).

当出现X-Forwarded-Proto标头时，情况会变得更糟.

The situation gets worse when X-Forwarded-Proto header is present.

我创建了一个简单的表来描述服务器的运行方式，我的问题是:

I created a simple table to describe how I would expect the server to behave and my question is:

您会实施相同的方法吗? 宣告的行为对您而言直观吗?预先感谢.

Would you implement it the same? Is declared behavior intuitive to you? Thanks in advance.

| # |       Request        | X-F...-Proto | X-F...-Host | X-F...-Port |      Output URL      |
|:-:|:---------------------|:------------:|:-----------:|:-----------:|:---------------------|
| 1 | http://a.com:8080/x  |     -no-     |     -no-    |    -no-     | http://a.com:8080/x  |
| 2 | http://a.com:8080/x  |    https     |     -no-    |    -no-     | https://a.com:8080/x |
| 3 | http://a.com:8080/x  |     -no-     |    b.com    |    -no-     | http://b.com/x       |
| 4 | http://a.com:8080/x  |     -no-     |  b.com:123  |    -no-     | http://b.com:123/x   |
| 5 | http://a.com:8080/x  |     -no-     |     -no-    |     123     | http://a.com:123/x   |
| 6 | http://a.com:8080/x  |     -no-     |    b.com    |     123     | http://b.com:123/x   |
| 7 | http://a.com:8080/x  |     -no-     |  b.com:123  |    -no-     | http://b.com:123/x   |
| 8 | http://a.com:8080/x  |     -no-     |  b.com:123  |     456     | http://b.com:456/x   |
| 9 | http://a.com:8080/x  |    https     |    b.com    |    -no-     | https://b.com/x      |
|10 | http://a.com:8080/x  |    https     |    b.com    |     123     | https://b.com:123/x  |
|11 | xyzz://a.com:8080/x  |     -no-     |    b.com    |    -no-     | xyzz://b.com:8080/x  |

请注意我认为最棘手的#3和#9.

Pay attention to #3 and #9 which are the most tricky I think.

推荐答案

由于目前尚无答案，我请公司的一些人员负责基础架构和Web服务器，他们同意提议的解决方案(表) 是正确的.这样:

As there is no answer so far, I asked a few people from our company that take care of infrastructures and web servers and they agreed that the proposed solution (table) is correct. So that:

• X-Forwarded-Host(不带端口)表示使用默认协议(80、443)

• X-Forwarded-Host without port means use protocol default (80, 443)

万一有人对代码(Java)感兴趣，这里是 Gravitee.io API管理平台，可修复以下行为:将应用程序默认端口(8083)用于协议默认端口(80、443)，并增加了对X-Forwarded-Port的支持.

In case anyone is interested in code (Java) = here is a pull request (PR) to Gravitee.io API Management platform that fixes behavior from the use of application default port (8083) to protocol default ports (80, 443) and adds support of X-Forwarded-Port.

这篇关于没有端口的HTTP X转发主机行为的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！