Opened 4 years ago
Closed 4 years ago
#2054 closed defect (invalid)
nginx returns a blank page
| Reported by: | 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)
Change History (6)
by , 4 years ago
| Attachment: | blank-response.curl.md added |
|---|
comment:1 by , 4 years 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 , 4 years 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 , 4 years ago
| Attachment: | Screenshot from 2020-10-03 18-14-59.png added |
|---|
by , 4 years ago
| Attachment: | nginx.conf added |
|---|
comment:3 by , 4 years ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
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.
example request, to reproduce the issue