php 从上游读取响应标头时如何修复上游发送的太大标头？

how to fix upstream sent too big header while reading response header from upstream?

提问by Hypothesis

I have this error in my log :

我的日志中有此错误：

upstream sent too big header while reading response header from upstream

从上游读取响应标头时，上游发送了太大的标头

And I tried to add

我试着添加

proxy_buffer_size   128k;
proxy_buffers   4 256k;
proxy_busy_buffers_size   256k;

to my nginx.conf http block but did not work

到我的 nginx.conf http 块但没有用

I also tried to add

我也尝试添加

fastcgi_buffer_size 128k;
fastcgi_buffers 4 256k;
fastcgi_busy_buffers_size 256k;

to my conf file but I could not locate any location ~ .php$ {

到我的 conf 文件，但我找不到任何位置 ~ .php$ {

So I wonder how I can over come this error ? adding

所以我想知道如何克服这个错误？添加

fastcgi_buffer_size 128k;
fastcgi_buffers 4 256k;
fastcgi_busy_buffers_size 256k;

to a hand made php block gives me nginx: [emerg] unknown directive "location" in /etc/nginx/nginx.conf:6

到一个手工制作的 php 块给了我nginx: [emerg] 在 /etc/nginx/nginx.conf:6 中的未知指令“位置”

回答by Aleksey Deryagin

Usually this parameters fix "upstream sent too big header" issue, and you dont need huge values for them :) And set them for http or server blocks, not location.

通常这个参数会修复“上游发送太大的标头”问题，并且你不需要为它们设置巨大的值:) 并将它们设置为 http 或服务器块，而不是位置。

server {
...
    fastcgi_buffers  16 16k;
    fastcgi_buffer_size  32k;
}

Also sometimes FirePHP for Firefox creates large headers, try to disable it temporarily.

此外，有时 FirePHP for Firefox 会创建大标题，请尝试暂时禁用它。

回答by ppostma1

upstream sent too big header while reading response header from upstreamis nginx's generic way of saying "I don't like what I'm seeing"

upstream sent too big header while reading response header from upstream是 nginx 说“我不喜欢我所看到的”的通用方式

1. Your upstream server thread crashed
2. The upstream server sent an invalid header back
3. The Notice/Warnings sent back from STDERR broke their buffer and both it and STDOUT were closed

1. 你的上游服务器线程崩溃了
2. 上游服务器发回了一个无效的标头
3. 从 STDERR 发回的通知/警告打破了他们的缓冲区，它和 STDOUT 都被关闭

3: Look at the error logs above the message, is it streaming with logged lines preceding the message? PHP message: PHP Notice: Undefined index:Example snippet from a loop my log file:

3：查看消息上方的错误日志，是否在消息前面带有记录行的流式传输？ PHP message: PHP Notice: Undefined index:循环我的日志文件的示例片段：

2015/11/23 10:30:02 [error] 32451#0: *580927 FastCGI sent in stderr: "PHP message: PHP Notice:  Undefined index: Firstname in /srv/www/classes/data_convert.php on line 1090
PHP message: PHP Notice:  Undefined index: Lastname in /srv/www/classes/data_convert.php on line 1090
... // 20 lines of same
PHP message: PHP Notice:  Undefined index: Firstname in /srv/www/classes/data_convert.php on line 1090
PHP message: PHP Notice:  Undefined index: Lastname in /srv/www/classes/data_convert.php on line 1090
PHP message: PHP Notice:
2015/11/23 10:30:02 [error] 32451#0: *580927 FastCGI sent in stderr: "ta_convert.php on line 1090
PHP message: PHP Notice:  Undefined index: Firstname

you can see in the 3rd line (from the 20 previous errors) the buffer limit was hit, broke, and the next thread wrote in over it. Nginx then closed the connection and returned 502 to the client.

您可以在第 3 行（来自之前的 20 个错误）中看到缓冲区限制已达到、已损坏，并且下一个线程将其写入。然后 Nginx 关闭连接并向客户端返回 502。

2: log all the headers sent per request, review them and make sure they conform to standards (nginx does not permit anything older than 24 hours to delete/expire a cookie, sending invalid content length because error messages were buffered before the content counted...)

2：记录每个请求发送的所有标头，检查它们并确保它们符合标准（nginx 不允许超过 24 小时的任何东西删除/过期 cookie，发送无效的内容长度，因为错误消息在内容计数之前被缓冲。 ..)

examples include:

例子包括：

<?php
//expire cookie
setcookie ( 'bookmark', '', strtotime('2012-01-01 00:00:00') );
// nginx will refuse this header response, too far past to accept
....
?>

and this:

和这个：

<?php
header('Content-type: image/jpg');
?>

<?php   //a space was injected into the output above this line
header('Content-length: ' . filesize('image.jpg') );
echo file_get_contents('image.jpg');
// error! the response is now 1-byte longer than header!!
?>

1: verify, or make a script log, to ensure your thread is reaching the correct end point and not exiting before completion.

1：验证或制作脚本日志，以确保您的线程到达正确的终点并且在完成之前不退出。