Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#2063 closed defect (invalid)

nginx reports seemingly incorrect “upstream split a header line in FastCGI records”

Reported by: MatTheCat@… Owned by:
Priority: minor Milestone:
Component: documentation Version: 1.19.x
Keywords: Cc:
uname -a: Linux 4e4771383dfc 5.8.14-arch1-1 #1 SMP PREEMPT Wed, 07 Oct 2020 23:59:46 +0000 x86_64 Linux
nginx -V: nginx version: nginx/1.19.3
built by gcc 9.3.0 (Alpine 9.3.0)
built with OpenSSL 1.1.1g 21 Apr 2020
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/ --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --with-perl_modules_path=/usr/lib/perl5/vendor_perl --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-Os -fomit-frame-pointer' --with-ld-opt=-Wl,--as-needed


This is a follow-up of where you will be able to find a way to reproduce the problem.

By enabling the debug mode I got

[debug] http fastcgi parser: -2
[debug] upstream split a header line in FastCGI records
[error] upstream sent too big header while reading response header from upstream

before every header could be sent. Note the [error] log seems inconsistent with the previous [debug].

I believe it has something to do with stderr so I checked but I’m not able to guess what’s going on.

Change History (3)

comment:1 by Maxim Dounin, 4 years ago

Resolution: invalid
Status: newclosed

Note the [error] log seems inconsistent with the previous [debug].

The error message suggests that the amount of data sent before the response header is fully available is larger than fastcgi_buffer_size.

From the description it looks like the error you see is completely correct, and indeed a result of errors being redirected to FastCGI stderr. The amount of data sent by the upstream from the response header start till its end is larger than fastcgi_buffer_size, likely due to errors being returned between the headers, hence the error. If you want nginx to handle large amount of errors being interleaved with the response headers, consider using larger fastcgi_buffer_size. Alternatively, consider reducing the amount of errors being generated.

The debug message "upstream split a header line in FastCGI records" is generated when nginx encounters a header line which spans beyond the data available for parsing, usually limited by the FastCGI record boundaries. This message indeed might appear if the data available for parsing is instead limited by the buffer size, as this is what seems to happen in your case. This is not a bug though, as the message is only a debugging one, and merely shows what nginx does, it is not expected to be perfectly correct. The error message which follows explains the real problem.

comment:2 by MatTheCat@…, 4 years ago

So I assumed the issue came from expose_php ( which sends a header before any log but it still doesn’t work; which means all logs must fit in fastcgi_buffer_size.

Is there a way to avoid putting logs in the same buffer than responses’ headers?

comment:3 by Maxim Dounin, 4 years ago

Is there a way to avoid putting logs in the same buffer than responses’ headers?

FastCGI frames with stderr stream can be skipped by nginx if they appear before the first stdout stream frame, or after the end of headers. If stderr stream is interleaved with stdout stream, both must fit into fastcgi_buffer_size.

Note: See TracTickets for help on using tickets.