November 26, 2011 07:41AM
I am experiencing this bug in a production system. (SSL closes are not detected, thus sockets stay in CLOSE_WAIT state forever -- nice DoS).

I was looking at nginx sources, and it seems that this bug has not been fixed.
The alternative is to use stunnel with the X-Forwarded-For patch, but that's way too messy.

In ngx_http_upstream_check_broken_connection(), there seems to be a different path for kqueue. What about modifying the poll/epoll behavior to detect disconnections for other event modules ? In ngx_epoll_add_connection(), we can add the EPOLLHUP event, and mark the connection as disconnected when processing HUP events instead of using the buggy MSG_PEEK hack
Subject Author Posted

Is there a bug in ngx_http_upstream_module's broken connection check code?

speedfirst June 23, 2011 12:14AM

Re: Is there a bug in ngx_http_upstream_module's broken connection check code?

Maxim Dounin June 23, 2011 08:14AM

Re: Is there a bug in ngx_http_upstream_module's broken connection check code?

speedfirst June 23, 2011 10:24PM

Re: Is there a bug in ngx_http_upstream_module's broken connection check code?

nviennot November 26, 2011 07:41AM

Re: Is there a bug in ngx_http_upstream_module's broken connection check code?

Maxim Dounin June 23, 2011 10:28PM

Re: Is there a bug in ngx_http_upstream_module's broken connection check code?

Maxim Dounin November 26, 2011 06:40PM

Re: Is there a bug in ngx_http_upstream_module's broken connection check code?

nviennot November 27, 2011 04:14PM



Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 250
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready