情况

我有一个REST API，可将JSON对象返回给其客户端。所述JSON响应的一部分是指向格式为“ http://myservice.com/servicePath/apiVersionA/123”的其他“链接”资源/对象的绝对URL。在示例URL中，“ servicePath”是我的服务的Web根，“ apiVersionA”是所使用的REST API的特定版本，“ 123”是实际资源的标识符。我的API在响应正文中返回绝对资源URL的事实是由我使用的协议规定的，我无权对此进行更改。

问题 我现在面临的问题是反向代理，更具体地说，我认为如何处理这些请求模式如下所示：

1. 客户端向反向代理发送请求“ GET http://myproxy.com/rest/apiVersionA/123”。
2. 反向代理将请求转发到其最终目的地：“ 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-注意代理所需的缺少的“剩余” URL路径元素。因此，在客户端发出的后续请求（例如，检索响应消息中引用的资源）中，代理服务器将不接受此URL。

问题

1. 我是否缺少明显的代理安全的HTTP标头，可以将原始请求URL传递给实际的REST API服务？
2. 如果没有，还有其他方法可以在服务中生成正确的绝对URL吗？

到目前为止，我已经考虑过使用自定义HTTP标头（可能会被中间代理删除），或者在反向代理上使用https://httpd.apache.org/docs/2.4/mod/mod_substitute.html之类的东西（我说这是不可能的，因为我无法控制客户或任何中介的网络基础架构）。我想到的另一个“非解决方案”是将其记录为我的API的一部分：“不要在HTTP代理上使用自定义URL路径元素”。这将允许我仅使用X-Forwarded-Host和X-Forwarded-Proto生成URL。

任何帮助表示赞赏！