Nginx-0.6.25

Changes with nginx 0.6.25 08 Jan
2008

*) Change: now the "server_name_in_redirect" directive is used 

instead
of the “server_name” directive’s special “*” parameter.

*) Change: now wildcard and regex names can be used as main name in 

a
“server_name” directive.

*) Change: the "satisfy_any" directive was replaced by the "satisfy"
   directive.

*) Workaround: old worker processes might hog CPU after 

reconfiguration
if they was run under Linux OpenVZ.

*) Feature: the "min_delete_depth" directive.

*) Bugfix: the COPY and MOVE methods did not work with single files.

*) Bugfix: the ngx_http_gzip_static_module did not allow the
   ngx_http_dav_module to work; bug appeared in 0.6.23.

*) Bugfix: socket leak in HTTPS mode if deferred accept was used.
   Thanks to Ben Maurer.

*) Bugfix: nginx could not be built without PCRE library; bug 

appeared
in 0.6.23.

Hi Igor,

Igor S. wrote:

Changes with nginx 0.6.25 08 Jan 2008
*) Bugfix: socket leak in HTTPS mode if deferred accept was used.
Thanks to Ben Maurer.

I don’t think the patch that’s in 0.6.25 actually fixes the deferred
accept issue. That issue caused the MSG_PEEK recv to return an EAGAIN
which resulted in read and write events not being handled on that
socket. The patch currently in the tree only fixes the issue where the
user completes the first half of the handshake but then stops
responding.

Also, is there any reason this isn’t merged into 0.5.x?

Thanks again for your help in dealing with these SSL issues,

  • Ben

On Tue, Jan 08, 2008 at 01:09:55PM -0500, Ben Maurer wrote:

user completes the first half of the handshake but then stops responding.
Yes, you are right. The attached patch should fix this case.

Also, is there any reason this isn’t merged into 0.5.x?

It will be merged after some time (about month).

Igor S. wrote:

socket. The patch currently in the tree only fixes the issue where the
user completes the first half of the handshake but then stops responding.

Yes, you are right. The attached patch should fix this case.

Also, is there any reason this isn’t merged into 0.5.x?

It will be merged after some time (about month).

If I remember correctly, according to netstat there were FDs that had
elements in the receive queue. This would suggest that more needs to be
done than to add a timeout (because these sockets had user data on them,
and thus should be added to the epoll)

  • b

On Wed, Jan 09, 2008 at 12:32:21AM -0500, Ben Maurer wrote:

which resulted in read and write events not being handled on that
elements in the receive queue. This would suggest that more needs to be
done than to add a timeout (because these sockets had user data on them,
and thus should be added to the epoll)

You are right, here is additional patch.