Opened 5 years ago

Closed 5 years ago

Last modified 13 months ago

#695 closed defect (duplicate)

Client connection hangs when responding to error_page 497 with 444

Reported by: www.google.com/accounts/o8/id?id=AItOawlMaWj0PyuBbkKmM58vtYnhnQdn6eNrdcs Owned by:
Priority: minor Milestone:
Component: nginx-core Version: 1.6.x
Keywords: error_page Cc:
uname -a: Linux some_host 3.13.0-43-generic #72-Ubuntu SMP Mon Dec 8 19:35:06 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
nginx -V: nginx version: nginx/1.6.2 TLS SNI support enabled configure arguments: --with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro' --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 --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-pcre-jit --with-ipv6 --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_addition_module --with-http_dav_module --with-http_geoip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_spdy_module --with-http_sub_module --with-http_xslt_module --with-mail --with-mail_ssl_module --add-module=/build/buildd/nginx-1.6.2/debian/modules/nginx-auth-pam --add-module=/build/buildd/nginx-1.6.2/debian/modules/nginx-dav-ext-module --add-module=/build/buildd/nginx-1.6.2/debian/modules/nginx-echo --add-module=/build/buildd/nginx-1.6.2/debian/modules/nginx-upstream-fair --add-module=/build/buildd/nginx-1.6.2/debian/modules/ngx_http_substitutions_filter_module

Description

Trying to set up a stealthy HTTPS server, I'd like to return 444 instead of the default 497 error:

server {
    server_name         some_server;
    keepalive_timeout   4;
    client_max_body_size 8192;

    listen              443 ssl;
    ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers         AES256-SHA:AES128-SHA;
    ssl_certificate     some_cert;
    ssl_certificate_key some_key;
    ssl_session_cache   shared:SSL:10m;
    ssl_session_timeout 10m;

    error_page 497 = @empty;

    location @empty {
        return 444;
    }

    location /some_end_point/ {
        ...
    }

    location / {
        return 444;
    }

My expectation is that when accessed through http://some_server:443 nginx immediately closes the connection.

Instead, the connection hangs until timing out or explicitly dropped by the client. This is reflected by $request_time in the log. Returning anything but 444 appears to work.

Change History (2)

comment:1 Changed 5 years ago by mdounin

  • Resolution set to duplicate
  • Status changed from new to closed

Thanks, this looks like another manifestation of the problem described in #274.

comment:2 Changed 13 months ago by Maxim Dounin <mdounin@…>

In 7354:1812f1d79d84/nginx:

Fixed socket leak with "return 444" in error_page (ticket #274).

Socket leak was observed in the following configuration:

error_page 400 = /close;

location = /close {

return 444;

}

The problem is that "return 444" triggers termination of the request,
and due to error_page termination thinks that it needs to use a posted
request to clear stack. But at the early request processing where 400
errors are generated there are no ngx_http_run_posted_requests() calls,
so the request is only terminated after an external event.

Variants of the problem include "error_page 497" instead (ticket #695)
and various other errors generated during early request processing
(405, 414, 421, 494, 495, 496, 501, 505).

The same problem can be also triggered with "return 499" and "return 408"
as both codes trigger ngx_http_terminate_request(), much like "return 444".

To fix this, the patch adds ngx_http_run_posted_requests() calls to
ngx_http_process_request_line() and ngx_http_process_request_headers()
functions, and to ngx_http_v2_run_request() and ngx_http_v2_push_stream()
functions in HTTP/2.

Since the ngx_http_process_request() function is now only called via
other functions which call ngx_http_run_posted_requests(), the call
there is no longer needed and was removed.

Note: See TracTickets for help on using tickets.