NGINX +节点。http-proxy =在header中添加的>长度

时间:2021-10-23 03:05:11

I use node.js behind nginx.The node.js app uses http-proxy.
Basically, the request gets to nginx and is then proxied to the node app:

我使用节点。js nginx的后面。的节点。js应用程序使用http代理。基本上,请求到达nginx,然后被代理到节点应用程序:

- if static files are requested, the node.js app serves them
- if non static files are requested, the node.js app proxyies the request to a second node.js app (using http-proxy npm).

The second case works perfectly when nginx is not in the picture. When nginx is added, the response is quite strange: it's surrounded with strange stuff:

当nginx不在图片中时,第二种情况可以很好地工作。当nginx被添加时,反应相当奇怪:它被奇怪的东西包围着:

"4c\r\n{ json stuff }\r\n0"

instead of

而不是

{ json stuff }

To summarize:

总结:

  1. (without nginx): request for dynamic content -> node.js -> proxy to another node.js app -> response sent back to the user is correct: { json stuff }

    (没有nginx):动态内容的请求——>节点。js ->代理到另一个节点。js app ->回复用户是正确的:{json素材}

  2. (with nginx): request for dynamic content -> node.js -> proxy to another node.js app -> response sent back to the user is not correct: "4c\r\n{ json stuff }\r\n0"

    (使用nginx):请求动态内容—>节点。js ->代理到另一个节点。发送给用户的>响应不正确:“4c\r\n{json stuff) \r\n0”

I still don't understand what's going on here... any idea ?

我还是不明白这是怎么回事……任何想法?

UPDATE

更新

Hmmm.... seems like it's linked to nginx adding additional header to the request...

嗯....似乎它被链接到nginx,向请求添加额外的header…

My nginx conf is:

我的nginx配置是:

upstream my_sock {
   server unix:/tmp/test.sock
   fail_timeout=0;
}
server {
   listen 8099;
   client_max_body_size 4G;
   server_name localhost;

   keepalive_timeout 5;

   location / {
     proxy_pass http://my_sock;
     proxy_redirect off;
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
     proxy_set_header Host $http_host;
   }
}

Any idea how to remove those additional headers ?

知道如何删除这些附加的标题吗?

UPDATE 2

更新2

the 4c added seems to be the length of the response I expect (json stuff). I then added:

添加的4c似乎是我期望的响应长度(json之类的)。然后我说:

proxy_set_header Content-Length '';

in nginx conf but nothing changed... I still have the 4c displayed... Arg...

在nginx conf中,没有什么改变……我仍然有4c显示……参数……

1 个解决方案

#1


3  

I know it's been 6 months, so you probably already know this, but in case someone else finds your question:

我知道已经6个月了,所以你可能已经知道了,但万一有人发现你的问题:

This is nginx outputting a chunked transfer encoding (Transfer-Encoding: chunked) - as you correctly stated the 4c is the length of the next chunk (in hex), and the 0 at the end (also hex) states there's nothing more coming (i.e. it's the end of the transfer). This will be misinterpreted by the browser/client if it doesn't also include the Transfer-Encoding: chunked header - I'd check this first.

这是nginx输出一个分块传输编码(传输编码:分块)——正如您正确地指出的那样,4c是下一个块的长度(在十六进制中),而最后的0(也是十六进制)表示没有其他的东西(例如,这是传输的结束)。如果浏览器/客户端不包含传输编码:分块头——我先检查一下。

NodeJS defaults to chunked encoding unless you explicitly set the Content-Length header. I don't have much experience with nginx but my guess is that if your NodeJS code outputs the Content-Length header correctly then nginx should forward this unless you tell it otherwise - so I'd check your NodeJS server's headers. You might also try updating your nginx - I have a vague recollection that earlier versions don't handle chunked transfer encoding very well, though I may be mistaken.

NodeJS默认使用分段编码,除非显式地设置内容长度头。我对nginx没有太多的经验,但是我猜如果NodeJS代码正确地输出了内容长度的header,那么nginx应该转发它,除非你告诉它不是这样——所以我要检查NodeJS服务器的header。您也可以尝试更新您的nginx——我模糊地记得,早期版本不能很好地处理分组传输编码,尽管我可能搞错了。

#1


3  

I know it's been 6 months, so you probably already know this, but in case someone else finds your question:

我知道已经6个月了,所以你可能已经知道了,但万一有人发现你的问题:

This is nginx outputting a chunked transfer encoding (Transfer-Encoding: chunked) - as you correctly stated the 4c is the length of the next chunk (in hex), and the 0 at the end (also hex) states there's nothing more coming (i.e. it's the end of the transfer). This will be misinterpreted by the browser/client if it doesn't also include the Transfer-Encoding: chunked header - I'd check this first.

这是nginx输出一个分块传输编码(传输编码:分块)——正如您正确地指出的那样,4c是下一个块的长度(在十六进制中),而最后的0(也是十六进制)表示没有其他的东西(例如,这是传输的结束)。如果浏览器/客户端不包含传输编码:分块头——我先检查一下。

NodeJS defaults to chunked encoding unless you explicitly set the Content-Length header. I don't have much experience with nginx but my guess is that if your NodeJS code outputs the Content-Length header correctly then nginx should forward this unless you tell it otherwise - so I'd check your NodeJS server's headers. You might also try updating your nginx - I have a vague recollection that earlier versions don't handle chunked transfer encoding very well, though I may be mistaken.

NodeJS默认使用分段编码,除非显式地设置内容长度头。我对nginx没有太多的经验,但是我猜如果NodeJS代码正确地输出了内容长度的header,那么nginx应该转发它,除非你告诉它不是这样——所以我要检查NodeJS服务器的header。您也可以尝试更新您的nginx——我模糊地记得,早期版本不能很好地处理分组传输编码,尽管我可能搞错了。