NGINX从proxy_pass响应读取正文 [英] NGINX read body from proxy_pass response

查看:716
本文介绍了NGINX从proxy_pass响应读取正文的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有两台服务器:

  1. NGINX(它将文件ID交换到文件路径)
  2. Golang(接受文件ID并返回其路径)

示例::当浏览器客户端向https://example.com/file?id=123发送请求时,NGINX将该请求代理到Golang服务器https://go.example.com/getpath?file_id=123,它将把响应返回给NGINX:

Ex: When browser client makes request to https://example.com/file?id=123, NGINX should proxy this request to Golang server https://go.example.com/getpath?file_id=123, which will return the response to NGINX:

{
  data: {
    filePath: "/static/..."
  },
  status: "ok"
}

然后NGINX应该从filePath获取值,并从该位置返回文件.

Then NGINX should get value from filePath and return file from the location.

所以问题是如何在NGINX中读取响应(获取filePath)?

推荐答案

我假设您是软件开发人员,并且对您的应用程序拥有完全控制权,因此这里无需在圆孔中强加方钉.

I assume you are software developer and your have full control over your application so there is no need to force square peg in a round hole here.

不同种类的反向代理支持 ESI(Edge Side Includes)技术,该技术使开发人员可以用静态文件的内容或上游服务器的响应主体替换响应主体的不同部分.

Different kinds of reverse proxies support ESI(Edge Side Includes) technology which allow developer to replace different parts of responce body with content of static files or with response bodies from upstream servers.

Nginx也具有这种技术.它称为 SSI(服务器端包含).

Nginx has such technology as well. It is called SSI (Server Side Includes).

location /file {
    ssi on;
    proxy_pass http://go.example.com;
}

您的上游服务器可以生成内容为<!--# include file="/path-to-static-files/some-static-file.ext" -->的主体,并且 nginx将用文件内容替换此体内指令.

Your upstream server can produce body with content <!--# include file="/path-to-static-files/some-static-file.ext" --> and nginx will replace this in-body directive with content of the file.

但是您提到了流式传输...

这意味着文件将具有任意大小,并且使用 SSI的构建响应肯定会吃掉宝贵的RAM 资源,因此我们需要计划#B .

It means that files will be of arbitrary sizes and building response with SSI would certainly eat precious RAM resources so we need a Plan #B.

有一种足够好"的方法可以将大文件提供给客户端,而无需向客户端显示文件的静态位置. 您可以使用nginx的错误处理程序根据上游服务器提供的信息来处理静态文件. 例如,上游服务器可以发送带有位置标头字段的重定向302,该标头字段包含文件的真实文件路径. 该响应未到达客户端,并被馈送到错误处理程序中.

There is "good enough" method to feed big files to the clients without showing static location of the file to the client. You can use nginx's error handler to server static files based on information supplied by upstream server. Upstream server for example can send back redirect 302 with Location header field containing real file path to the file. This response does not reach the client and is feed into error handler.

以下是配置示例:

location /file {
    error_page 302 = @service_static_file;
    proxy_intercept_errors on;
    proxy_set_header Host            $host;
    proxy_pass http://go.example.com;
}

location @service_static_file {
    root /hidden-files;
    try_files $upstream_http_location 404.html;
}

使用这种方法,您可以在不控制系统文件的情况下提供文件,而又不会过载系统.

要使其正常工作,上游服务器应使用状态302和典型的位置:"字段进行响应,nginx将使用位置内容在静态文件的新"根目录中查找文件.

For this to work your upstream server should respond with status 302 and with typical "Location:" field and nginx will use location content to find the file in the "new" root for static files.

此方法之所以具有足够好"类型(而不是完美)的原因,是因为它不支持部分请求(即范围:字节...)

The reason for this method to be of "good enough" type (instead of perfect) because it does not support partial requests (i.e. Range: bytes ...)

这篇关于NGINX从proxy_pass响应读取正文的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆