来自代码的反向代理和 HTTP 请求

Posted 2023-02-25

【中文标题】来自代码的反向代理和 HTTP 请求

【英文标题】：Reverse proxy and HTTP request from code

【发布时间】：2017-11-17 19:43:05

【问题描述】：

当您不知道自己是否在反向代理后面运行（例如 HTTPD）。

Web 应用程序在 Web 服务器上的根“/”上下文中运行 代理使用上下文“/proxy”运行，该上下文代理该 Web 服务器

应通过 /proxy/index.html 请求从浏览器访问 index.html。 但是，如果 Web 应用程序中有一些代码（例如 myscript.js）以编程方式发送 HTTP 请求（例如 xhr.open("???/resource")。

问题来了，因为代码将此 HTTP 请求发送到 /resource，而不是发送到 /proxy/resource。

换句话说，Web 应用程序（在浏览器中运行）的代码不知道是否有代理。请记住，应用程序可以在代理之后运行，但可能根本没有任何代理。我想到了 3 个解决方案：

1) Web 应用程序通过从当前 window.location.path 解析上下文（例如 /proxy）自动解析上下文并根据它发送 xhr

2) 增强 Web 应用程序以要求用户对代理进行一些额外配置，如果设置了上下文，它会附加上下文

3) 以某种方式配置代理，以将非代理类 URL 重新发送到 Web 服务器 1:1（例如 /proxy -> webserver/，/ -> webserver/）

哪一个是“正确”的，还是有其他选择？

【参考方案1】：

后端 Web 应用程序不应该知道在它们之上或之前是否有代理。理想情况下，他们应该生活在自己的上下文路径中，例如。 /application/ 如果他们需要发送重定向而不使用主机名或 url 方案，只需 URL-Path /application/*

那么理想情况下，您可以根据您的第 3 个场景执行简单的反向代理指令：

ProxyPass /XXX/ http://backend/application/
ProxyPassReverse /XXX/ http://backend/application/

【讨论】：

我同意他们不应该意识到这一点。所以你建议写 xhr.open("/application")？它可以在没有主机名和方案的情况下工作吗？如果应用程序存在于根上下文中，它会工作吗？

顺便说一句，这不是关于重定向，而是关于请求一些数据（例如来自 HTTP API）。即使发送没有主机名和方案：例如我认为 xhr.open("/application") 不起作用（因为它缺少 /XXX （所以它不会到达代理）。

要么我不了解您，要么您不了解我，您的应用程序位于反向代理“后面”，假设客户端发出请求，通过反向代理，反向代理通过将其添加到您的应用程序中，您的所有应用程序都应仅响应 url-path、主机名或 url 方案，除非对其他地方进行外部重定向，否则永远不应包含在内。反向代理将处理客户端使用的方案和主机名，并在与提供的配置相匹配时保留它。

是的，正如你所说，我们不了解自己:-) 你描述的情况是好的。我的意思是当我的应用程序的一部分被加载到浏览器（客户端）并需要查询同一个应用程序的后端（服务器）时。客户端的应用程序部分（在浏览器中）是例如执行 HTTP 请求的 JS 代码（以编程方式从代码中）。所以从技术上讲，这个客户端应用程序是“提前”代理，需要使用包含代理上下文的 URL 请求服务器（代理后面）。

那么我想对我来说合乎逻辑的事情是为这些过去添加特定的指令，或者根本不使用反向代理。