【发布时间】：2021-03-18 19:22:42
【问题描述】：
情况
我有一个 REST API 可以将 JSON 对象返回给它的客户端。部分所述 JSON 响应是“http://myservice.com/servicePath/apiVersionA/123”形式的其他“链接”资源/对象的绝对 URL。在示例 URL 中，“servicePath”是我的服务的 Web 根目录，“apiVersionA”是正在使用的 REST API 的特定版本，“123”是实际资源的标识符。我的 API 在响应正文中返回绝对资源 URL 的事实是由我使用的协议规定的，我无权更改它。
问题 我现在面临的问题是反向代理，更具体地说，我假设它们如何处理如下请求模式：
- 客户端向反向代理发送请求“GET http://myproxy.com/rest/apiVersionA/123"”。
- 反向代理将请求转发到其最终目的地：“GET http://myservice.com/servicePath/apiVersionA/123"。请注意，代理修改了请求的主机名和 URL 路径（“rest”更改为“servicePath”）。李>
AFAIK，通常的嫌疑人（即 HTTP 标头“Forwarded”、“X-Forwarded-For”、“X-Forwarded-Host”等）仅包含 IP 地址或域名，但不包含整个 URL 路径。所以现在在最好的情况下，我可以生成像“http://myproxy.com/apiVersionA/123”这样的 URL——注意代理所需的缺少的“rest”URL 路径元素。因此，在客户端发出的后续请求中，代理将不会接受此 URL，例如检索响应消息中引用的资源。
问题
- 我是否缺少一个明显的代理安全 HTTP 标头，可以将原始请求 URL 传送到实际的 REST API 服务？
- 如果没有，是否有其他方法可以在我的服务中生成正确的绝对 URL？
到目前为止，我已经考虑过使用自定义 HTTP 标头（可能会被中间代理删除），或者在反向代理上使用 https://httpd.apache.org/docs/2.4/mod/mod_substitute.html 之类的东西（我想说这是不可能的，因为我没有控制我的客户或任何中介的网络基础设施）。我想出的另一个“非解决方案”是将其记录为我的 API 的一部分：“不要在 HTTP 代理上使用自定义 URL 路径元素”。这将允许我仅使用 X-Forwarded-Host 和 X-Forwarded-Proto 生成 URL。
感谢任何帮助！
【问题讨论】：
-
“我的 API 在响应正文中返回绝对资源 URL 的事实是由我使用的协议规定的，我无权更改它。” - 我认为这是协议中的一个错误。它应该支持相对引用。
-
同意，因为协议的其他部分允许相对 URI。但鉴于这是一个国际标准，我能够改变这种行为的机会相当渺茫——尽管我会将此作为一个问题提出。与此同时，我希望有一个更务实的解决方案。
标签： http http-headers reverse-proxy forwarding