Opened 3 weeks ago

Closed 2 weeks ago

#2054 closed defect (invalid)

nginx returns a blank page

Reported by: ramanathan.kashinathan.contentstack.com@… Owned by:
Priority: major Milestone:
Component: nginx-core Version: 1.18.x
Keywords: Cc: ramanathan.kashinathan.contentstack.com@…
uname -a: Linux ramanathan-Vostro-5481 5.4.0-47-generic #51-Ubuntu SMP Fri Sep 4 19:50:52 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
nginx -V: nginx version: nginx/1.18.0 (Ubuntu)
built with OpenSSL 1.1.1f 31 Mar 2020
TLS SNI support enabled
configure arguments: --with-cc-opt='-g -O2 -fdebug-prefix-map=/build/nginx-5J5hor/nginx-1.18.0=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -fPIC' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --modules-path=/usr/lib/nginx/modules --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-compat --with-pcre-jit --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_v2_module --with-http_dav_module --with-http_slice_module --with-threads --with-http_addition_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module=dynamic --with-http_sub_module --with-http_xslt_module=dynamic --with-stream=dynamic --with-stream_ssl_module --with-mail=dynamic --with-mail_ssl_module

Description

Hi there,

We have noticed that when the header size is too large, nginx returns a blank page.

We tried to set the error log level to debug but we are not seeing any logs for the same.

Attaching an example in cURL

Attachments (3)

blank-response.curl.md (8.8 KB ) - added by ramanathan.kashinathan.contentstack.com@… 3 weeks ago.
example request, to reproduce the issue
Screenshot from 2020-10-03 18-14-59.png (176.8 KB ) - added by ramanathan.kashinathan.contentstack.com@… 2 weeks ago.
nginx.conf (1.5 KB ) - added by ramanathan.kashinathan.contentstack.com@… 2 weeks ago.

Download all attachments as: .zip

Change History (6)

by ramanathan.kashinathan.contentstack.com@…, 3 weeks ago

Attachment: blank-response.curl.md added

example request, to reproduce the issue

comment:1 by Maxim Dounin, 3 weeks ago

We have noticed that when the header size is too large, nginx returns a blank page.

As far as we are aware, nginx never returns a blank page unless explicitly configured to do so. It may, however, return an error, or close the connection, or generate HTTP/2 or SSL-level errors in some cases. In particular, size of HTTP headers is subject to various limitations. Depending on the protocol used, different limits might apply.

For HTTP/1.x, large_client_header_buffers is the relevant limit. Once it is hit, nginx will return 400 (Bad Request) error:

$ curl -H 'Foo: '`perl -e 'print "X" x 8192;'` http://127.0.0.1:8080/
<html>
<head><title>400 Request Header Or Cookie Too Large</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>Request Header Or Cookie Too Large</center>
<hr><center>nginx/1.19.3</center>
</body>
</html>

Relevant error log message will be logged at the "info" level:

2020/10/03 03:11:19 [info] 80532#100108: *1 client sent too long header line: "Foo: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX..." while reading client request headers, client: 127.0.0.1, server: , request: "GET / HTTP/1.1", host: "127.0.0.1:8080"

In case of HTTP/2, relevant limits are http2_max_field_size and http2_max_header_size. Once hit, nginx will generate an HTTP/2-level error ENHANCE_YOUR_CALM. Note though that curl isn't good at displaying HTTP/2-level errors, and instead pretends the connection is closed without any error indication:

$ curl -k -H 'Foo: '`perl -e 'print "X" x 8192;'` https://127.0.0.1:8443/
curl: (52) Empty reply from server

Relevant error log message will be logged at the "info" level:

2020/10/03 03:09:05 [info] 80409#100126: *5 client exceeded http2_max_field_size limit while processing HTTP/2 connection, client: 127.0.0.1, server: 0.0.0.0:8443

The example request you've provided does not seem to hit any of the limits though, at least in the default configuration. This, especially if you aren't seeing any of the above info-level error messages (assuming you've set the logging level to info, see error_log), might indicate that the "blank page" you are seeing isn't returned by nginx, but rather by a backend server.

If you still think there is a bug in nginx, please provide a full self-contained example to reproduce this - that is, an nginx configuration along with an example request. Please also provide the request result you are seeing.

comment:2 by ramanathan.kashinathan.contentstack.com@…, 2 weeks ago

Unfortunately, setting nginx lines to debug OR info doesn't log any kind of error or access logs.

I am attaching the file using to test, along with the request being made to the backend server.

There's no request hitting the backend server either, which indicates that the nginx isn't forwarding the request.

by ramanathan.kashinathan.contentstack.com@…, 2 weeks ago

by ramanathan.kashinathan.contentstack.com@…, 2 weeks ago

Attachment: nginx.conf added

comment:3 by Maxim Dounin, 2 weeks ago

Resolution: invalid
Status: newclosed

The screenshot provided shows the 400 Bad Request response, which is in line with large_client_header_buffers limit being hit with large request headers.

Unfortunately, it is not possible to conclude why you are not seeing appropriate logs, since you've provided only a minor part of the configuration - it lacks included files, and logging settings can be easily overridden for a particular server block. Consider looking at the full configuration as shown by nginx -T.

Either way, it doesn't seem to be a bug in nginx, but rather a correct behaviour matching your configuration. If you want to allow requests with large request headers, consider tuning large_client_header_buffers appropriately.

Note: See TracTickets for help on using tickets.