基于 HTTP 方法选择上游服务器是不好的做法吗？
我想知道使用反向代理根据所使用的 HTTP 方法选择上游服务器是否是一种不好的做法？
背景是我有一个任意的 Web 服务器，它处理带有一些逻辑的 POST 请求。相同的资源还包含静态内容，可以使用 GET 检索这些内容。经过一些基准测试后，我意识到 nginx 处理静态内容的速度比我的任意 Web 服务器更快。
我检查了使用nginx内部转发传入请求的选项，这是可行的。
但这会导致不同的服务器仅依赖于发出 GET 或 POST 来提供不同的资源，包括不同的标头字段。
I'm wondering if it is bad practice to have a reverse proxy that selects the upstream server depending on the HTTP method used?
The background is that I have an abitrary web server that handles POST requests with some logic behind. The same resources also contain static content, that can be retrieved using GET. After some benchmarking I realized that nginx would handle the static content way faster than my abitrary web server doing this.
I checked the option to forward incoming requests internally using nginx, which is feasible.
But this would lead to the fact that different servers would serve a distinct resource, only depending on issuing a GET or POST, including different header fields.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
不，这不是坏习惯，只要您不需要在服务器上存储持久的每个用户会话数据，按任务的性质对任务进行分区就完全没问题。
No, it's not bad practice, partitioning the tasks by the nature of the task is perfectly fine, as long as you don't need to store persistent per-user-session data on the server.