From wandenberg at gmail.com Sat Oct 1 03:52:37 2011 From: wandenberg at gmail.com (Wandenberg Peixoto) Date: Sat, 1 Oct 2011 00:52:37 -0300 Subject: Patch for test reading function Message-ID: Hi, I would like to suggest a small patch for function ngx_http_test_reading to properly works under https connections. Using SSL_peek function to detect when request is ended by the client. I hope you accept it. Regards, Wandenberg -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test_reading_with_ssl-nginx.1.1.2-1.1.4.patch Type: text/x-patch Size: 936 bytes Desc: not available URL: From ssehic at gmail.com Sat Oct 1 05:52:37 2011 From: ssehic at gmail.com (=?UTF-8?B?U3JlYnJlbmtvIMWgZWhpxIc=?=) Date: Sat, 1 Oct 2011 07:52:37 +0200 Subject: [PATCH] slaying the BEAST (TLS 1.0 exploiting) Message-ID: Hi, You've probably heard it already. SSL was hacked and broken. You can read about it at http://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl/. Some more commentary at http://blogs.cisco.com/security/beat-the-beast-with-tls/ As it turns out, OpenSSL people implemented a fix for this almost 10 years ago. Details at http://www.openssl.org/~bodo/tls-cbc.txt Attached is a patch against 1.0.6 which introduces "ssl_dont_insert_empty_fragments" flag to control whether this workaround is enabled or not. Currently, it was hardcoded to disabled. This patch makes it optional. Note: this patch breaks certain old browsers which choke on the workaround. This was tested with IE6. Comments? Cheers, Srebrenko -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-ssl_dont_insert_fragments.patch Type: text/x-patch Size: 2748 bytes Desc: not available URL: From q2011oct at gmail.com Sat Oct 1 06:16:31 2011 From: q2011oct at gmail.com (J.Q. S.) Date: Sat, 1 Oct 2011 02:16:31 -0400 Subject: Need advice on implementing alternate upstream protocol Message-ID: I could use some advice on how best to proceed - I am exploring the idea of using a datagram protocol to broadcast http-like requests to a cluster of backend servers, where one of the servers will respond with either a small payload to send directly to the browser or a pointer to a network device where a file can be read and sent back. I won't know which server will respond, responses could come back in a different order then I send them, and each worker would have a single datagram socket for receiving responses to queries from the same worker. The most significant question I need to answer, would it be better to try and do this within the upstream/proxy framework nginx provides, or to do an independent module. If working with upstream/proxy, I could use some advice on where to hook in my datagram connect/send/receive functions. If an independent module, any advice other then maybe looking at ngx_resolver and maybe the fastcgi module as starting points? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Sat Oct 1 09:50:57 2011 From: mdounin at mdounin.ru (Maxim Dounin) Date: Sat, 1 Oct 2011 13:50:57 +0400 Subject: [PATCH] slaying the BEAST (TLS 1.0 exploiting) In-Reply-To: References: Message-ID: <20111001095057.GB1137@mdounin.ru> Hello! On Sat, Oct 01, 2011 at 07:52:37AM +0200, Srebrenko ?ehi? wrote: > Hi, > > You've probably heard it already. SSL was hacked and broken. You can > read about it at > http://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl/. > Some more commentary at > http://blogs.cisco.com/security/beat-the-beast-with-tls/ > > As it turns out, OpenSSL people implemented a fix for this almost 10 > years ago. Details at http://www.openssl.org/~bodo/tls-cbc.txt > > Attached is a patch against 1.0.6 which introduces > "ssl_dont_insert_empty_fragments" flag to control whether this > workaround is enabled or not. Currently, it was hardcoded to disabled. > This patch makes it optional. > > Note: this patch breaks certain old browsers which choke on the > workaround. This was tested with IE6. > > Comments? The patch won't help to stop BEAST (CVE-2011-3389), you need fix on *client* side to stop it. More details about the attack may be found here: http://vnhacker.blogspot.com/2011/09/beast.html https://bugzilla.mozilla.org/show_bug.cgi?id=665814 The only server-side workaround I'm currently aware of is using non-CBC ciphers, i.e. ssl_ciphers RC4-SHA; (Of course migrating to the TLS 1.1+ is a better option, but it's not yet here.) For OpenSSL's "insert empty fragments" workaround on a server side, situation hasn't changed much since 2003: there is problem, there are no known attacks, and workaround causes major interoperability problems. (Probably working on better workaround in OpenSSL would be a good idea. It looks like Chrome's one-byte one causes much less problems.) Maxim Dounin From mdounin at mdounin.ru Sat Oct 1 11:10:52 2011 From: mdounin at mdounin.ru (Maxim Dounin) Date: Sat, 1 Oct 2011 15:10:52 +0400 Subject: Patch for test reading function In-Reply-To: References: Message-ID: <20111001111052.GE1137@mdounin.ru> Hello! On Sat, Oct 01, 2011 at 12:52:37AM -0300, Wandenberg Peixoto wrote: > Hi, > > I would like to suggest a small patch for function ngx_http_test_reading to > properly works under https connections. > Using SSL_peek function to detect when request is ended by the client. > > I hope you accept it. > > Regards, > Wandenberg > --- src/http/ngx_http_request.c 2011-10-01 00:27:17.895845001 -0300 > +++ src/http/ngx_http_request.c 2011-10-01 00:15:46.055845002 -0300 > @@ -2353,7 +2353,15 @@ > > #endif > > +#if (NGX_HTTP_SSL) > + if (c->ssl != NULL) { > + n = SSL_peek(c->ssl->connection, buf, 1); > + } else { > + n = recv(c->fd, buf, 1, MSG_PEEK); > + } > +#else > n = recv(c->fd, buf, 1, MSG_PEEK); > +#endif > > if (n == 0) { > rev->eof = 1; > @@ -2363,9 +2371,19 @@ > goto closed; > > } else if (n == -1) { > - err = ngx_socket_errno; > +#if (NGX_HTTP_SSL) > + if (c->ssl != NULL) { > + err = SSL_get_error(c->ssl->connection, n); > + } else { > + err = ngx_socket_errno; > + } > + > + if ((err != NGX_EAGAIN) && (err != SSL_ERROR_WANT_READ) && (err != SSL_ERROR_WANT_WRITE)) { > +#else > + err = ngx_socket_errno; > > - if (err != NGX_EAGAIN) { > + if (err != NGX_EAGAIN) { > +#endif > rev->eof = 1; > c->error = 1; > (Just a side note: there are multiple style issues in the patch.) I would like to see this abstracted in connection API, with something like c->peek() (handled by ssl events code for ssl connections, much like it's currently done for c->recv()). Maxim Dounin From ssehic at gmail.com Sun Oct 2 13:31:08 2011 From: ssehic at gmail.com (=?UTF-8?B?U3JlYnJlbmtvIMWgZWhpxIc=?=) Date: Sun, 2 Oct 2011 15:31:08 +0200 Subject: [PATCH] slaying the BEAST (TLS 1.0 exploiting) In-Reply-To: <20111001095057.GB1137@mdounin.ru> References: <20111001095057.GB1137@mdounin.ru> Message-ID: On Sat, Oct 1, 2011 at 11:50 AM, Maxim Dounin wrote: Hi, > The patch won't help to stop BEAST (CVE-2011-3389), you need fix > on *client* side to stop it. ?More details about the attack > may be found here: To quote the Cisco article: "Another thing to highlight is that OpenSSL implemented a feature where they send an ?empty TLS record? immediately before they send a message. This empty TLS record causes a change in the CBC state where people consider it to give the message ?a new IV? that the attacker can?t predict. This feature in OpenSSL is disabled with the ?SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS? option and it?s also included in the ?SSL_OP_ALL? option. In OpenSSL versions 0.9.6d and later, the protocol-level mitigation is enabled by default, thus making it not vulnerable to the BEAST attack." > The only server-side workaround I'm currently aware of is using > non-CBC ciphers, i.e. > > ? ?ssl_ciphers RC4-SHA; Agree. RC4 is the only generally available stream cipher supported by most browser. However, that too might break some browsers as the choice of ciphers gets pretty limited. > For OpenSSL's "insert empty fragments" workaround on a server > side, situation hasn't changed much since 2003: there is problem, > there are no known attacks, and workaround causes major > interoperability problems. True. To my best knowledge though, only IE6.0 and lower are affected which should not be that many. All moderns browsers should work just fine with this workaround. > (Probably working on better workaround in OpenSSL would be a good > idea. It looks like Chrome's one-byte one causes much less > problems.) Anything requiring patches to be applied to OpenSSL takes a lot of time. It's probably faster to update the browsers. I still think the patch is valid enough, but maybe just default to disabled (like it is now), but give people the choice? Thanks, Srebrenko From mdounin at mdounin.ru Sun Oct 2 14:38:56 2011 From: mdounin at mdounin.ru (Maxim Dounin) Date: Sun, 2 Oct 2011 18:38:56 +0400 Subject: [PATCH] slaying the BEAST (TLS 1.0 exploiting) In-Reply-To: References: <20111001095057.GB1137@mdounin.ru> Message-ID: <20111002143856.GH1137@mdounin.ru> Hello! On Sun, Oct 02, 2011 at 03:31:08PM +0200, Srebrenko ?ehi? wrote: > On Sat, Oct 1, 2011 at 11:50 AM, Maxim Dounin wrote: > > Hi, > > > The patch won't help to stop BEAST (CVE-2011-3389), you need fix > > on *client* side to stop it. ?More details about the attack > > may be found here: > > To quote the Cisco article: > > "Another thing to highlight is that OpenSSL implemented a feature > where they send an ?empty TLS record? immediately before they send a > message. This empty TLS record causes a change in the CBC state where > people consider it to give the message ?a new IV? that the attacker > can?t predict. This feature in OpenSSL is disabled with the > ?SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS? option and it?s also included in > the ?SSL_OP_ALL? option. In OpenSSL versions 0.9.6d and later, the > protocol-level mitigation is enabled by default, thus making it not > vulnerable to the BEAST attack." The quote is correct, but as you probably noticed it doesn't say anywhere that this workaround should be used on server to prevent BEAST. It should be used on sending side, i.e. client in case of BEAST. > > The only server-side workaround I'm currently aware of is using > > non-CBC ciphers, i.e. > > > > ? ?ssl_ciphers RC4-SHA; > > Agree. RC4 is the only generally available stream cipher supported by > most browser. However, that too might break some browsers as the > choice of ciphers gets pretty limited. This was just example. If you want to use RC4 in real life, something like this should be used: ssl_ciphers RC4:HIGH:!aNULL:!MD5; ssl_prefer_server_ciphers on; It will prefer RC4 ciphers, though allow others if RC4 is not available. > > For OpenSSL's "insert empty fragments" workaround on a server > > side, situation hasn't changed much since 2003: there is problem, > > there are no known attacks, and workaround causes major > > interoperability problems. > > True. To my best knowledge though, only IE6.0 and lower are affected > which should not be that many. All moderns browsers should work just > fine with this workaround. IE6 is still used by more than 2% of users over the world. > > (Probably working on better workaround in OpenSSL would be a good > > idea. It looks like Chrome's one-byte one causes much less > > problems.) > > Anything requiring patches to be applied to OpenSSL takes a lot of > time. It's probably faster to update the browsers. > > I still think the patch is valid enough, but maybe just default to > disabled (like it is now), but give people the choice? It may make sense, but right now it's at least misleading: people may think they are safe from BEAST with this workaround enabled on server, while they are not. Maxim Dounin From ssehic at gmail.com Sun Oct 2 17:29:04 2011 From: ssehic at gmail.com (=?UTF-8?B?U3JlYnJlbmtvIMWgZWhpxIc=?=) Date: Sun, 2 Oct 2011 19:29:04 +0200 Subject: [PATCH] slaying the BEAST (TLS 1.0 exploiting) In-Reply-To: <20111002143856.GH1137@mdounin.ru> References: <20111001095057.GB1137@mdounin.ru> <20111002143856.GH1137@mdounin.ru> Message-ID: On Sun, Oct 2, 2011 at 4:38 PM, Maxim Dounin wrote: Hi, > The quote is correct, but as you probably noticed it doesn't say > anywhere that this workaround should be used on server to prevent > BEAST. ?It should be used on sending side, i.e. client in case of > BEAST. Yes I did notice. Different sources on the Internet state different things. However, the general consensus does say that it's a client side only. > It may make sense, but right now it's at least misleading: people > may think they are safe from BEAST with this workaround enabled on > server, while they are not. You have me convinced. Let's forget about the patch for now. Thanks for your input Maxim. Highly appreciated. Cheers, Srebrenko From valery+nginxen at grid.net.ru Mon Oct 3 08:59:24 2011 From: valery+nginxen at grid.net.ru (Valery Kholodkov) Date: Mon, 3 Oct 2011 09:59:24 +0100 (BST) Subject: Need advice on implementing alternate upstream protocol In-Reply-To: Message-ID: <29204513.5612.1317632364506.JavaMail.root@zone.mtgsy.net> ----- J.Q. S. wrote: > I could use some advice on how best to proceed - > > I am exploring the idea of using a datagram protocol to broadcast http-like > requests to a cluster of backend servers, where one of the servers will > respond with either a small payload to send directly to the browser or a > pointer to a network device where a file can be read and sent back. I won't > know which server will respond, responses could come back in a different > order then I send them, and each worker would have a single datagram socket > for receiving responses to queries from the same worker. > > The most significant question I need to answer, would it be better to try > and do this within the upstream/proxy framework nginx provides, or to do an > independent module. For datagram protocol it's better to do this outside of the upstream/proxy framework, as most of that code you don't need. > If working with upstream/proxy, I could use some advice on where to hook in > my datagram connect/send/receive functions. > > If an independent module, any advice other then maybe looking at > ngx_resolver and maybe the fastcgi module as starting points? For UDP stuff look at udplog module sources: http://www.grid.net.ru/nginx/udplog.en.html -- Regards, Valery Kholodkov From tzury.by at reguluslabs.com Mon Oct 3 18:51:22 2011 From: tzury.by at reguluslabs.com (Tzury Bar Yochay) Date: Mon, 3 Oct 2011 20:51:22 +0200 Subject: developing an nginx module Message-ID: Hi, I am looking to hire an experienced nginx developer which will be able to write me a small module that I am willing to develop but go no time. If you are such one and interested in this, kindly mail me back at tzury.by at gmail.com and I will get back to you with more details. looking forward hearing from you, Tzury -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmdrclueless at gmail.com Tue Oct 4 14:24:15 2011 From: cmdrclueless at gmail.com (Brian Weaver) Date: Tue, 4 Oct 2011 10:24:15 -0400 Subject: Nginx + Large File Support Message-ID: <3B44772F-38C0-4C80-A17D-4ED5C189C097@gmail.com> Hello, I have what I hope is a simply question, has anyone tried compiling Nginx with support for large files on Linux. I've run into an issue where a co-worker is trying to upload a file in excess of 2GB in size and it's failing. I've modified the compilation options to support large files and we're going to test it. I'm just wondering if anyone had tried it and had any wisdom they would mind sharing. Thanks -- Weave From igor at sysoev.ru Tue Oct 4 17:45:38 2011 From: igor at sysoev.ru (Igor Sysoev) Date: Tue, 4 Oct 2011 21:45:38 +0400 Subject: Nginx + Large File Support In-Reply-To: <3B44772F-38C0-4C80-A17D-4ED5C189C097@gmail.com> References: <3B44772F-38C0-4C80-A17D-4ED5C189C097@gmail.com> Message-ID: <20111004174537.GB16444@nginx.com> On Tue, Oct 04, 2011 at 10:24:15AM -0400, Brian Weaver wrote: > Hello, > > I have what I hope is a simply question, has anyone tried compiling Nginx with support for large files on Linux. I've run into an issue where a co-worker is trying to upload a file in excess of 2GB in size and it's failing. I've modified the compilation options to support large files and we're going to test it. I'm just wondering if anyone had tried it and had any wisdom they would mind sharing. nginx supports Linux LFS with #define _FILE_OFFSET_BITS 64 since version 0.0.1. -- Igor Sysoev From cmdrclueless at gmail.com Tue Oct 4 19:13:11 2011 From: cmdrclueless at gmail.com (Brian Weaver) Date: Tue, 4 Oct 2011 15:13:11 -0400 Subject: Nginx + Large File Support In-Reply-To: <20111004174537.GB16444@nginx.com> References: <3B44772F-38C0-4C80-A17D-4ED5C189C097@gmail.com> <20111004174537.GB16444@nginx.com> Message-ID: <611E9BEC-F781-46A0-B387-161AA5D4EE4A@gmail.com> Darn. I had modified my build to pass in the output of 'getconf LFS_CFLAGS', 'getconf LFS_LDFLAGS', and 'getconf LFS_LIBS' to make it more portable. Well, if that's the case any idea why Nginx would accept a post in excess of 2GiB in size even when the 'client_max_body_size' is set sufficiently? -- Weave On Oct 4, 2011, at 13:45 , Igor Sysoev wrote: > On Tue, Oct 04, 2011 at 10:24:15AM -0400, Brian Weaver wrote: >> Hello, >> >> I have what I hope is a simply question, has anyone tried compiling Nginx with support for large files on Linux. I've run into an issue where a co-worker is trying to upload a file in excess of 2GB in size and it's failing. I've modified the compilation options to support large files and we're going to test it. I'm just wondering if anyone had tried it and had any wisdom they would mind sharing. > > nginx supports Linux LFS with > #define _FILE_OFFSET_BITS 64 > since version 0.0.1. > > -- > Igor Sysoev > > _______________________________________________ > nginx-devel mailing list > nginx-devel at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-devel From igor at sysoev.ru Tue Oct 4 19:18:04 2011 From: igor at sysoev.ru (Igor Sysoev) Date: Tue, 4 Oct 2011 23:18:04 +0400 Subject: Nginx + Large File Support In-Reply-To: <611E9BEC-F781-46A0-B387-161AA5D4EE4A@gmail.com> References: <3B44772F-38C0-4C80-A17D-4ED5C189C097@gmail.com> <20111004174537.GB16444@nginx.com> <611E9BEC-F781-46A0-B387-161AA5D4EE4A@gmail.com> Message-ID: <20111004191804.GA18283@nginx.com> On Tue, Oct 04, 2011 at 03:13:11PM -0400, Brian Weaver wrote: > Darn. I had modified my build to pass in the output of 'getconf LFS_CFLAGS', 'getconf LFS_LDFLAGS', and 'getconf LFS_LIBS' to make it more portable. > > Well, if that's the case any idea why Nginx would accept a post in excess of 2GiB in size even when the 'client_max_body_size' is set sufficiently? Debugging log should help: http://nginx.org/en/docs/debugging_log.html I believe that client uses 32-bit number for Content-Length. > -- Weave > > On Oct 4, 2011, at 13:45 , Igor Sysoev wrote: > > > On Tue, Oct 04, 2011 at 10:24:15AM -0400, Brian Weaver wrote: > >> Hello, > >> > >> I have what I hope is a simply question, has anyone tried compiling Nginx with support for large files on Linux. I've run into an issue where a co-worker is trying to upload a file in excess of 2GB in size and it's failing. I've modified the compilation options to support large files and we're going to test it. I'm just wondering if anyone had tried it and had any wisdom they would mind sharing. > > > > nginx supports Linux LFS with > > #define _FILE_OFFSET_BITS 64 > > since version 0.0.1. > > > > -- > > Igor Sysoev > > > > _______________________________________________ > > nginx-devel mailing list > > nginx-devel at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-devel > > _______________________________________________ > nginx-devel mailing list > nginx-devel at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-devel -- Igor Sysoev From cmdrclueless at gmail.com Tue Oct 4 21:33:55 2011 From: cmdrclueless at gmail.com (Brian Weaver) Date: Tue, 4 Oct 2011 17:33:55 -0400 Subject: Nginx + Large File Support In-Reply-To: <20111004191804.GA18283@nginx.com> References: <3B44772F-38C0-4C80-A17D-4ED5C189C097@gmail.com> <20111004174537.GB16444@nginx.com> <611E9BEC-F781-46A0-B387-161AA5D4EE4A@gmail.com> <20111004191804.GA18283@nginx.com> Message-ID: I'm actually trying to help someone else so I'll ask them to look at the post headers in firebug. I didn't consider that the client might have a 32-bit limitation. Thanks! On Oct 4, 2011, at 15:18 , Igor Sysoev wrote: > Debugging log should help: > http://nginx.org/en/docs/debugging_log.html > > I believe that client uses 32-bit number for Content-Length. > From xiaohanhoho at gmail.com Wed Oct 5 14:34:19 2011 From: xiaohanhoho at gmail.com (=?GB2312?B?0KS6rQ==?=) Date: Wed, 5 Oct 2011 22:34:19 +0800 Subject: [PATCH 1 of 1 RFC] Better recheck of dead upstream servers In-Reply-To: References: Message-ID: recently,i begain to use nginx.1.1.4 to test upstream keepalived,but i found it olny i must set the keepalive_timeout X (X>0),the upstream keepalive can work , isn't it? 2011/9/27 Maxim Dounin > # HG changeset patch > # User Maxim Dounin > # Date 1317126090 -14400 > # Node ID a0fc6910248f8f92ff8b7cc1465ba3fd8cd8c52d > # Parent a0228f0e9fe2ad166324a80bc915ad8ec1050dcc > Better recheck of dead upstream servers. > > Previously nginx used to mark backend again as live as soon as fail_timeout > passes (10s by default) since last failure. On the other hand, detecting > dead backend takes up to 60s (proxy_connect_timeout) in typical situation > "backend is down and doesn't respond to any packets". This resulted in > suboptimal behaviour in the above situation (up to 23% of requests were > directed to dead backend with default settings). > > More detailed description of the problem may be found here (in Russian): > http://mailman.nginx.org/pipermail/nginx-ru/2011-August/042172.html > > Fix is to only allow one request after fail_timeout passes, and > mark backend as "live" only if this request succeeds. > > Note that with new code backend will not be marked "live" unless "check" > request is completed, and this may take a while in some specific workloads > (e.g. streaming). This is believed to be acceptable. > > diff --git a/src/http/modules/ngx_http_upstream_ip_hash_module.c > b/src/http/modules/ngx_http_upstream_ip_hash_module.c > --- a/src/http/modules/ngx_http_upstream_ip_hash_module.c > +++ b/src/http/modules/ngx_http_upstream_ip_hash_module.c > @@ -185,8 +185,8 @@ ngx_http_upstream_get_ip_hash_peer(ngx_p > break; > } > > - if (now - peer->accessed > peer->fail_timeout) { > - peer->fails = 0; > + if (now - peer->checked > peer->fail_timeout) { > + peer->checked = now; > break; > } > } > diff --git a/src/http/ngx_http_upstream_round_robin.c > b/src/http/ngx_http_upstream_round_robin.c > --- a/src/http/ngx_http_upstream_round_robin.c > +++ b/src/http/ngx_http_upstream_round_robin.c > @@ -443,8 +443,8 @@ ngx_http_upstream_get_round_robin_peer(n > break; > } > > - if (now - peer->accessed > peer->fail_timeout) { > - peer->fails = 0; > + if (now - peer->checked > peer->fail_timeout) { > + peer->checked = now; > break; > } > > @@ -491,8 +491,8 @@ ngx_http_upstream_get_round_robin_peer(n > break; > } > > - if (now - peer->accessed > peer->fail_timeout) { > - peer->fails = 0; > + if (now - peer->checked > peer->fail_timeout) { > + peer->checked = now; > break; > } > > @@ -663,15 +663,16 @@ ngx_http_upstream_free_round_robin_peer( > return; > } > > + peer = &rrp->peers->peer[rrp->current]; > + > if (state & NGX_PEER_FAILED) { > now = ngx_time(); > > - peer = &rrp->peers->peer[rrp->current]; > - > /* ngx_lock_mutex(rrp->peers->mutex); */ > > peer->fails++; > peer->accessed = now; > + peer->checked = now; > > if (peer->max_fails) { > peer->current_weight -= peer->weight / peer->max_fails; > @@ -686,6 +687,14 @@ ngx_http_upstream_free_round_robin_peer( > } > > /* ngx_unlock_mutex(rrp->peers->mutex); */ > + > + } else { > + > + /* mark peer live if check passed */ > + > + if (peer->accessed < peer->checked) { > + peer->fails = 0; > + } > } > > rrp->current++; > diff --git a/src/http/ngx_http_upstream_round_robin.h > b/src/http/ngx_http_upstream_round_robin.h > --- a/src/http/ngx_http_upstream_round_robin.h > +++ b/src/http/ngx_http_upstream_round_robin.h > @@ -23,6 +23,7 @@ typedef struct { > > ngx_uint_t fails; > time_t accessed; > + time_t checked; > > ngx_uint_t max_fails; > time_t fail_timeout; > > _______________________________________________ > nginx-devel mailing list > nginx-devel at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Wed Oct 5 14:49:19 2011 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 5 Oct 2011 18:49:19 +0400 Subject: [PATCH 1 of 1 RFC] Better recheck of dead upstream servers In-Reply-To: References: Message-ID: <20111005144918.GW1137@mdounin.ru> Hello! On Wed, Oct 05, 2011 at 10:34:19PM +0800, ?? wrote: > recently,i begain to use nginx.1.1.4 to test upstream keepalived,but i found > it olny i must set the keepalive_timeout X (X>0),the upstream keepalive can > work , isn't it? For upstream keepalive to work you have to enable keepalive connections on backend server(s). If you are using nginx on backend - you have to use keepalive_timeout to enable keepalive support on it. Maxim Dounin p.s. Your question is clearly unrelated to the patch about dead servers recheck. Please don't hijack unrelated threads. Thank you. From info at walterdalmut.com Sat Oct 8 21:42:05 2011 From: info at walterdalmut.com (Walter Dal Mut) Date: Sat, 8 Oct 2011 23:42:05 +0200 Subject: Nginx write new module as filter. Message-ID: Hi everybody I am new to nginx and actually I am interested on nginx extensions. I need to write a new module for nginx and compile a version with this module. I don't want to write down an handler but a filter, I need to work on headers. For that reason I start my module using gzip as a base and cut different part that I don't want use. I compile nginx with my module and all works fine. After that I start the server with my personal configuration (corley on;) in the main conf file and the server start correctly. The problem is that my module seems never used. The filter functionality is pretty simple, I want to force text/plain header. I don't understand why my module is never called. Any one can help me? The main filename is: *ngx_http_corley_filter_module.c* The configuration filename is:* config* * * The config content: * * ngx_addon_name=ngx_http_corley_filter_module HTTP_MODULES="$HTTP_MODULES ngx_http_corley_filter_module" NGX_ADDON_SRCS="$NGX_ADDON_SRCS $ngx_addon_dir/ngx_http_corley_filter_module.c" The ngx_http_corley_filter_module.c content: #include #include #include typedef struct { ngx_flag_t enable; } ngx_http_corley_conf_t; static ngx_int_t ngx_http_corley_filter_init(ngx_conf_t *cf); static void * ngx_http_corley_create_conf(ngx_conf_t *cf); static char * ngx_http_corley_merge_conf(ngx_conf_t *cf, void *parent, void *child); static void * ngx_http_corley_create_conf(ngx_conf_t *cf); static ngx_command_t ngx_http_corley_filter_commands[] = { { ngx_string("corley"), NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|NGX_HTTP_LIF_CONF|NGX_CONF_FLAG, ngx_conf_set_flag_slot, NGX_HTTP_LOC_CONF_OFFSET, offsetof(ngx_http_corley_conf_t, enable), NULL }, ngx_null_command }; static ngx_http_module_t ngx_http_corley_filter_module_ctx = { NULL, /* preconfiguration */ ngx_http_corley_filter_init, /* postconfiguration */ NULL, /* create main configuration */ NULL, /* init main configuration */ NULL, /* create server configuration */ NULL, /* merge server configuration */ ngx_http_corley_create_conf, /* create location configuration */ ngx_http_corley_merge_conf /* merge location configuration */ }; ngx_module_t ngx_http_corley_filter_module = { NGX_MODULE_V1, &ngx_http_corley_filter_module_ctx, /* module context */ ngx_http_corley_filter_commands, /* module directives */ NGX_HTTP_MODULE, /* module type */ NULL, /* init master */ NULL, /* init module */ NULL, /* init process */ NULL, /* init thread */ NULL, /* exit thread */ NULL, /* exit process */ NULL, /* exit master */ NGX_MODULE_V1_PADDING }; static ngx_http_output_header_filter_pt ngx_http_next_header_filter; static ngx_http_output_body_filter_pt ngx_http_next_body_filter; *static ngx_int_t ngx_http_corley_header_filter(ngx_http_request_t *r) { ngx_http_corley_conf_t *conf; conf = ngx_http_get_module_loc_conf(r, ngx_http_corley_filter_module); ngx_table_elt_t *h; h = ngx_list_push(&r->headers_out.headers); if (h == NULL) { return NGX_ERROR; } h->hash = 1; ngx_str_set(&h->key, "Content-Encoding"); ngx_str_set(&h->value, "text/plain"); r->headers_out.content_encoding = h; r->main_filter_need_in_memory = 1; ngx_http_clear_content_length(r); ngx_http_clear_accept_ranges(r); return ngx_http_next_header_filter(r); } * static ngx_int_t ngx_http_corley_body_filter(ngx_http_request_t *r, ngx_chain_t *in) { ngx_log_error(NGX_LOG_ERR, r->connection->log, 0, "not well formed XML document"); return ngx_http_next_body_filter(r, in); } static void * ngx_http_corley_create_conf(ngx_conf_t *cf) { ngx_http_corley_conf_t *conf; conf = ngx_pcalloc(cf->pool, sizeof(ngx_http_corley_conf_t)); if (conf == NULL) { return NULL; } /* * set by ngx_pcalloc(): * * conf->bufs.num = 0; * conf->types = { NULL }; * conf->types_keys = NULL; */ conf->enable = NGX_CONF_UNSET; return conf; } static char * ngx_http_corley_merge_conf(ngx_conf_t *cf, void *parent, void *child) { ngx_http_corley_conf_t *prev = parent; ngx_http_corley_conf_t *conf = child; ngx_conf_merge_value(conf->enable, prev->enable, 0); return NGX_CONF_OK; } static ngx_int_t ngx_http_corley_filter_init(ngx_conf_t *cf) { ngx_http_next_header_filter = ngx_http_top_header_filter; ngx_http_top_header_filter = ngx_http_corley_header_filter; ngx_http_next_body_filter = ngx_http_top_body_filter; ngx_http_top_body_filter = ngx_http_corley_body_filter; return NGX_OK; } Thanks to all. Walter -------------- next part -------------- An HTML attachment was scrubbed... URL: From simohayha.bobo at gmail.com Sun Oct 9 02:00:21 2011 From: simohayha.bobo at gmail.com (Simon Liu) Date: Sun, 9 Oct 2011 10:00:21 +0800 Subject: Nginx write new module as filter. In-Reply-To: References: Message-ID: You should use HTTP_AUX_FILTER_MODULES="$HTTP_AUX_FILTER_MODULES ngx_http_corley_filter_module" rather than HTTP_MODULES="$HTTP_MODULES ngx_http_corley_filter_module" On Sun, Oct 9, 2011 at 5:42 AM, Walter Dal Mut wrote: > Hi everybody I am new to nginx and actually I am interested on nginx > extensions. > > I need to write a new module for nginx and compile a version with this > module. I don't want to write down an handler but a filter, I need to work > on headers. > > For that reason I start my module using gzip as a base and cut different > part that I don't want use. > > I compile nginx with my module and all works fine. After that I start the > server with my personal configuration (corley on;) in the main conf file and > the server start correctly. The problem is that my module seems never used. > The filter functionality is pretty simple, I want to force text/plain > header. > > I don't understand why my module is never called. Any one can help me? > > The main filename is: *ngx_http_corley_filter_module.c* > The configuration filename is:* config* > * > * > The config content: > * > * > ngx_addon_name=ngx_http_corley_filter_module > HTTP_MODULES="$HTTP_MODULES ngx_http_corley_filter_module" > NGX_ADDON_SRCS="$NGX_ADDON_SRCS > $ngx_addon_dir/ngx_http_corley_filter_module.c" > > > The ngx_http_corley_filter_module.c content: > > #include > #include > #include > > typedef struct { > ngx_flag_t enable; > } ngx_http_corley_conf_t; > > static ngx_int_t ngx_http_corley_filter_init(ngx_conf_t *cf); > static void * ngx_http_corley_create_conf(ngx_conf_t *cf); > static char * ngx_http_corley_merge_conf(ngx_conf_t *cf, void *parent, void > *child); > static void * ngx_http_corley_create_conf(ngx_conf_t *cf); > > static ngx_command_t ngx_http_corley_filter_commands[] = { > > { ngx_string("corley"), > > NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|NGX_HTTP_LIF_CONF|NGX_CONF_FLAG, > ngx_conf_set_flag_slot, > NGX_HTTP_LOC_CONF_OFFSET, > offsetof(ngx_http_corley_conf_t, enable), > NULL }, > > ngx_null_command > }; > > > static ngx_http_module_t ngx_http_corley_filter_module_ctx = { > NULL, /* preconfiguration */ > ngx_http_corley_filter_init, /* postconfiguration */ > NULL, /* create main configuration */ > NULL, /* init main configuration */ > NULL, /* create server configuration */ > NULL, /* merge server configuration */ > ngx_http_corley_create_conf, /* create location configuration > */ > ngx_http_corley_merge_conf /* merge location configuration > */ > }; > > > ngx_module_t ngx_http_corley_filter_module = { > NGX_MODULE_V1, > &ngx_http_corley_filter_module_ctx, /* module context */ > ngx_http_corley_filter_commands, /* module directives */ > NGX_HTTP_MODULE, /* module type */ > NULL, /* init master */ > NULL, /* init module */ > NULL, /* init process */ > NULL, /* init thread */ > NULL, /* exit thread */ > NULL, /* exit process */ > NULL, /* exit master */ > NGX_MODULE_V1_PADDING > }; > > > static ngx_http_output_header_filter_pt ngx_http_next_header_filter; > static ngx_http_output_body_filter_pt ngx_http_next_body_filter; > > > *static ngx_int_t > ngx_http_corley_header_filter(ngx_http_request_t *r) > { > ngx_http_corley_conf_t *conf; > conf = ngx_http_get_module_loc_conf(r, ngx_http_corley_filter_module); > > ngx_table_elt_t *h; > > h = ngx_list_push(&r->headers_out.headers); > if (h == NULL) { > return NGX_ERROR; > } > > h->hash = 1; > ngx_str_set(&h->key, "Content-Encoding"); > ngx_str_set(&h->value, "text/plain"); > > r->headers_out.content_encoding = h; > > r->main_filter_need_in_memory = 1; > > ngx_http_clear_content_length(r); > ngx_http_clear_accept_ranges(r); > > > return ngx_http_next_header_filter(r); > } > * > > static ngx_int_t > ngx_http_corley_body_filter(ngx_http_request_t *r, ngx_chain_t *in) > { > ngx_log_error(NGX_LOG_ERR, r->connection->log, 0, > "not well formed XML document"); > return ngx_http_next_body_filter(r, in); > } > > static void * > ngx_http_corley_create_conf(ngx_conf_t *cf) > { > ngx_http_corley_conf_t *conf; > > conf = ngx_pcalloc(cf->pool, sizeof(ngx_http_corley_conf_t)); > if (conf == NULL) { > return NULL; > } > > /* > * set by ngx_pcalloc(): > * > * conf->bufs.num = 0; > * conf->types = { NULL }; > * conf->types_keys = NULL; > */ > > conf->enable = NGX_CONF_UNSET; > > return conf; > } > > > static char * > ngx_http_corley_merge_conf(ngx_conf_t *cf, void *parent, void *child) > { > ngx_http_corley_conf_t *prev = parent; > ngx_http_corley_conf_t *conf = child; > > ngx_conf_merge_value(conf->enable, prev->enable, 0); > > return NGX_CONF_OK; > } > > static ngx_int_t > ngx_http_corley_filter_init(ngx_conf_t *cf) > { > ngx_http_next_header_filter = ngx_http_top_header_filter; > ngx_http_top_header_filter = ngx_http_corley_header_filter; > > ngx_http_next_body_filter = ngx_http_top_body_filter; > ngx_http_top_body_filter = ngx_http_corley_body_filter; > > return NGX_OK; > } > > Thanks to all. > Walter > > _______________________________________________ > nginx-devel mailing list > nginx-devel at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-devel > -- douban:www.douban.com/people/mustang/ blog: www.pagefault.info twitter: www.twitter.com/minibobo weibo: www.weibo.com/diaoliang -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiaohanhoho at gmail.com Sun Oct 9 07:22:34 2011 From: xiaohanhoho at gmail.com (=?GB2312?B?0KS6rQ==?=) Date: Sun, 9 Oct 2011 15:22:34 +0800 Subject: [PATCH 1 of 3] Upstream: clearing of u->peer.connection on close In-Reply-To: References: Message-ID: HI , i want to use 1.1.4 to instead of stable version online ,because we need the upstream keepalive to do sth, do you recommend it? 2011/9/25 Maxim Dounin > # HG changeset patch > # User Maxim Dounin > # Date 1316882053 -14400 > # Node ID f1cbffaa09dcc5e8d9f3fc888abcac8e6e7c38b3 > # Parent 6c19b251b92674710573c472e8aba406fa72da50 > Upstream: clearing of u->peer.connection on close. > > This fixes crashes observed with some 3rd party balancer modules. Standard > balancer modules (round-robin and ip hash) explicitly set pc->connection > (aka u->peer.connection) to NULL and aren't affected. > > diff --git a/src/http/ngx_http_upstream.c b/src/http/ngx_http_upstream.c > --- a/src/http/ngx_http_upstream.c > +++ b/src/http/ngx_http_upstream.c > @@ -2927,6 +2927,7 @@ ngx_http_upstream_next(ngx_http_request_ > } > > ngx_close_connection(u->peer.connection); > + u->peer.connection = NULL; > } > > #if 0 > > _______________________________________________ > nginx-devel mailing list > nginx-devel at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at walterdalmut.com Sun Oct 9 08:09:38 2011 From: info at walterdalmut.com (Walter Dal Mut) Date: Sun, 9 Oct 2011 10:09:38 +0200 Subject: Nginx write new module as filter. In-Reply-To: References: Message-ID: Thank you Simon, Now the filter is engaged and works. Thank you so much. Walter On 9 October 2011 04:00, Simon Liu wrote: > You should use HTTP_AUX_FILTER_MODULES="$HTTP_AUX_FILTER_MODULES > ngx_http_corley_filter_module" rather than HTTP_MODULES="$HTTP_MODULES > ngx_http_corley_filter_module" > > On Sun, Oct 9, 2011 at 5:42 AM, Walter Dal Mut wrote: > >> Hi everybody I am new to nginx and actually I am interested on nginx >> extensions. >> >> I need to write a new module for nginx and compile a version with this >> module. I don't want to write down an handler but a filter, I need to work >> on headers. >> >> For that reason I start my module using gzip as a base and cut different >> part that I don't want use. >> >> I compile nginx with my module and all works fine. After that I start the >> server with my personal configuration (corley on;) in the main conf file and >> the server start correctly. The problem is that my module seems never used. >> The filter functionality is pretty simple, I want to force text/plain >> header. >> >> I don't understand why my module is never called. Any one can help me? >> >> The main filename is: *ngx_http_corley_filter_module.c* >> The configuration filename is:* config* >> * >> * >> The config content: >> * >> * >> ngx_addon_name=ngx_http_corley_filter_module >> HTTP_MODULES="$HTTP_MODULES ngx_http_corley_filter_module" >> NGX_ADDON_SRCS="$NGX_ADDON_SRCS >> $ngx_addon_dir/ngx_http_corley_filter_module.c" >> >> >> The ngx_http_corley_filter_module.c content: >> >> #include >> #include >> #include >> >> typedef struct { >> ngx_flag_t enable; >> } ngx_http_corley_conf_t; >> >> static ngx_int_t ngx_http_corley_filter_init(ngx_conf_t *cf); >> static void * ngx_http_corley_create_conf(ngx_conf_t *cf); >> static char * ngx_http_corley_merge_conf(ngx_conf_t *cf, void *parent, >> void *child); >> static void * ngx_http_corley_create_conf(ngx_conf_t *cf); >> >> static ngx_command_t ngx_http_corley_filter_commands[] = { >> >> { ngx_string("corley"), >> >> NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|NGX_HTTP_LIF_CONF|NGX_CONF_FLAG, >> ngx_conf_set_flag_slot, >> NGX_HTTP_LOC_CONF_OFFSET, >> offsetof(ngx_http_corley_conf_t, enable), >> NULL }, >> >> ngx_null_command >> }; >> >> >> static ngx_http_module_t ngx_http_corley_filter_module_ctx = { >> NULL, /* preconfiguration */ >> ngx_http_corley_filter_init, /* postconfiguration */ >> NULL, /* create main configuration */ >> NULL, /* init main configuration */ >> NULL, /* create server configuration >> */ >> NULL, /* merge server configuration */ >> ngx_http_corley_create_conf, /* create location configuration >> */ >> ngx_http_corley_merge_conf /* merge location configuration >> */ >> }; >> >> >> ngx_module_t ngx_http_corley_filter_module = { >> NGX_MODULE_V1, >> &ngx_http_corley_filter_module_ctx, /* module context */ >> ngx_http_corley_filter_commands, /* module directives */ >> NGX_HTTP_MODULE, /* module type */ >> NULL, /* init master */ >> NULL, /* init module */ >> NULL, /* init process */ >> NULL, /* init thread */ >> NULL, /* exit thread */ >> NULL, /* exit process */ >> NULL, /* exit master */ >> NGX_MODULE_V1_PADDING >> }; >> >> >> static ngx_http_output_header_filter_pt ngx_http_next_header_filter; >> static ngx_http_output_body_filter_pt ngx_http_next_body_filter; >> >> >> *static ngx_int_t >> ngx_http_corley_header_filter(ngx_http_request_t *r) >> { >> ngx_http_corley_conf_t *conf; >> conf = ngx_http_get_module_loc_conf(r, ngx_http_corley_filter_module); >> >> ngx_table_elt_t *h; >> >> h = ngx_list_push(&r->headers_out.headers); >> if (h == NULL) { >> return NGX_ERROR; >> } >> >> h->hash = 1; >> ngx_str_set(&h->key, "Content-Encoding"); >> ngx_str_set(&h->value, "text/plain"); >> >> r->headers_out.content_encoding = h; >> >> r->main_filter_need_in_memory = 1; >> >> ngx_http_clear_content_length(r); >> ngx_http_clear_accept_ranges(r); >> >> >> return ngx_http_next_header_filter(r); >> } >> * >> >> static ngx_int_t >> ngx_http_corley_body_filter(ngx_http_request_t *r, ngx_chain_t *in) >> { >> ngx_log_error(NGX_LOG_ERR, r->connection->log, 0, >> "not well formed XML document"); >> return ngx_http_next_body_filter(r, in); >> } >> >> static void * >> ngx_http_corley_create_conf(ngx_conf_t *cf) >> { >> ngx_http_corley_conf_t *conf; >> >> conf = ngx_pcalloc(cf->pool, sizeof(ngx_http_corley_conf_t)); >> if (conf == NULL) { >> return NULL; >> } >> >> /* >> * set by ngx_pcalloc(): >> * >> * conf->bufs.num = 0; >> * conf->types = { NULL }; >> * conf->types_keys = NULL; >> */ >> >> conf->enable = NGX_CONF_UNSET; >> >> return conf; >> } >> >> >> static char * >> ngx_http_corley_merge_conf(ngx_conf_t *cf, void *parent, void *child) >> { >> ngx_http_corley_conf_t *prev = parent; >> ngx_http_corley_conf_t *conf = child; >> >> ngx_conf_merge_value(conf->enable, prev->enable, 0); >> >> return NGX_CONF_OK; >> } >> >> static ngx_int_t >> ngx_http_corley_filter_init(ngx_conf_t *cf) >> { >> ngx_http_next_header_filter = ngx_http_top_header_filter; >> ngx_http_top_header_filter = ngx_http_corley_header_filter; >> >> ngx_http_next_body_filter = ngx_http_top_body_filter; >> ngx_http_top_body_filter = ngx_http_corley_body_filter; >> >> return NGX_OK; >> } >> >> Thanks to all. >> Walter >> >> _______________________________________________ >> nginx-devel mailing list >> nginx-devel at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-devel >> > > > > -- > douban:www.douban.com/people/mustang/ > > blog: www.pagefault.info > > twitter: www.twitter.com/minibobo > > weibo: www.weibo.com/diaoliang > > > _______________________________________________ > nginx-devel mailing list > nginx-devel at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Sun Oct 9 19:36:40 2011 From: mdounin at mdounin.ru (Maxim Dounin) Date: Sun, 9 Oct 2011 23:36:40 +0400 Subject: [PATCH 1 of 3] Upstream: clearing of u->peer.connection on close In-Reply-To: References: Message-ID: <20111009193640.GV1137@mdounin.ru> Hello! On Sun, Oct 09, 2011 at 03:22:34PM +0800, ?? wrote: > HI , i want to use 1.1.4 to instead of stable version online ,because we > need the upstream keepalive to do sth, do you recommend it? Use 1.1.5 instead. Maxim Dounin From agentzh at gmail.com Thu Oct 13 07:10:25 2011 From: agentzh at gmail.com (agentzh) Date: Thu, 13 Oct 2011 15:10:25 +0800 Subject: [PATCH] clear modules' contexts in ngx_http_named_location Message-ID: Hello! Here attaches a patch for the nginx 1.1.5 core to fix a long standing bug in the ngx_http_named_location function. I think we should clear out all the modules' contexts there just as in ngx_http_internal_redirect, or we'll observe weird issues due to left-over obsolete module contexts from the original request before the jump. Here is a bad case in action: http://www.ruby-forum.com/topic/2765027 Regards, -agentzh --- nginx-1.1.5/src/http/ngx_http_core_module.c 2011-09-27 19:14:02.000000000 +0800 +++ nginx-1.1.5-patched/src/http/ngx_http_core_module.c 2011-10-13 15:02:24.414550532 +0800 @@ -2542,6 +2542,9 @@ r->content_handler = NULL; r->loc_conf = (*clcfp)->loc_conf; + /* clear the modules contexts */ + ngx_memzero(r->ctx, sizeof(void *) * ngx_http_max_module); + ngx_http_update_location_config(r); cmcf = ngx_http_get_module_main_conf(r, ngx_http_core_module); -------------- next part -------------- A non-text attachment was scrubbed... Name: nginx-1.1.5-named_location_clear_mods_ctx.patch Type: application/octet-stream Size: 533 bytes Desc: not available URL: From delta.yeh at gmail.com Thu Oct 13 12:22:28 2011 From: delta.yeh at gmail.com (Delta Yeh) Date: Thu, 13 Oct 2011 20:22:28 +0800 Subject: nginx segment fault when it need write error log but no error file is configured Message-ID: Hi, During my test of nginx_udplog module, I run into a nginx segment fault. In nginx conf file, I don't set nginx error log, I set access_udplog 192.168.1.1 main; but 192.168.1.1 udp port 514 is not open. When I send a request, nginx crashed. gdb info: #0 0x0805a4b0 in ngx_log_error_core (level=4, log=0x812c3d4, err=111, fmt=0x80e2437 "send() failed") at src/core/ngx_log.c:93 #1 0x080636f4 in ngx_connection_error (c=0x812fc60, err=111, text=0x80e2437 "send() failed") at src/core/ngx_connection.c:1093 #2 0x080708e5 in ngx_unix_send (c=0x812fc60, (gdb) frame 0 #0 0x0805a4b0 in ngx_log_error_core (level=4, log=0x812c3d4, err=111, fmt=0x80e2437 "send() failed") at src/core/ngx_log.c:93 93 if (log->file->fd == NGX_INVALID_FILE) { (gdb) p *log $1 = {log_level = 4, file = 0x0, connection = 0, handler = 0, data = 0x0, action = 0x80ebfc6 "logging"} It seems log->file should be checked also. If I set error log file, nginx won't crash. From mdounin at mdounin.ru Thu Oct 13 19:24:15 2011 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 13 Oct 2011 23:24:15 +0400 Subject: [PATCH] clear modules' contexts in ngx_http_named_location In-Reply-To: References: Message-ID: <20111013192415.GB1137@mdounin.ru> Hello! On Thu, Oct 13, 2011 at 03:10:25PM +0800, agentzh wrote: > Hello! > > Here attaches a patch for the nginx 1.1.5 core to fix a long standing > bug in the ngx_http_named_location function. > > I think we should clear out all the modules' contexts there just as in > ngx_http_internal_redirect, or we'll observe weird issues due to > left-over obsolete module contexts from the original request before > the jump. Here is a bad case in action: > http://www.ruby-forum.com/topic/2765027 > > Regards, > -agentzh > > --- nginx-1.1.5/src/http/ngx_http_core_module.c 2011-09-27 > 19:14:02.000000000 +0800 > +++ nginx-1.1.5-patched/src/http/ngx_http_core_module.c 2011-10-13 > 15:02:24.414550532 +0800 > @@ -2542,6 +2542,9 @@ > r->content_handler = NULL; > r->loc_conf = (*clcfp)->loc_conf; > > + /* clear the modules contexts */ > + ngx_memzero(r->ctx, sizeof(void *) * ngx_http_max_module); > + > ngx_http_update_location_config(r); > > cmcf = ngx_http_get_module_main_conf(r, ngx_http_core_module); I think this is a right change. To Igor: previous discussion I was able to find is here (in Russian): http://mailman.nginx.org/pipermail/nginx-ru/2009-July/026730.html Since then, I can't recall any single case where not clearing module contexts was beneficial. On the other hand, the above case is at least 2nd one when it strikes badly. Maxim Dounin From jan at ryngle.com Thu Oct 13 21:09:58 2011 From: jan at ryngle.com (Jan Janak) Date: Thu, 13 Oct 2011 17:09:58 -0400 Subject: [PATCH] Let modules override the Connection header in locally generated HTTP responses Message-ID: Hello, The attached patch creates a new field in r->headers_out called "connection". Modules could use this field to override the automatically generated Connection header in locally generated HTTP responses. This is needed to perform a HTTP connection upgrade, for example, in a WebSocket handshake. Please consider including this patch in one of future releases of nginx. Thanks a lot! -Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Let-modules-override-the-Connection-header.patch Type: text/x-patch Size: 4586 bytes Desc: not available URL: From megwoo at gmail.com Sat Oct 15 21:01:01 2011 From: megwoo at gmail.com (Megan Woo) Date: Sat, 15 Oct 2011 14:01:01 -0700 Subject: Nginx / Magento Expert Message-ID: We are looking for an Nginx / Magento Expert to help us set up a second store (multi-store in Magento). The original developer set up some Nginx redirects that we think are causing some problems. Does anyone know a Nginx / Magento Expert they can recommend?? Thanks! -- Megan Woo Web Developer From mdounin at mdounin.ru Sat Oct 15 21:42:31 2011 From: mdounin at mdounin.ru (Maxim Dounin) Date: Sun, 16 Oct 2011 01:42:31 +0400 Subject: [PATCH] clear modules' contexts in ngx_http_named_location In-Reply-To: References: Message-ID: <20111015214231.GG1137@mdounin.ru> Hello! On Thu, Oct 13, 2011 at 03:10:25PM +0800, agentzh wrote: > Hello! > > Here attaches a patch for the nginx 1.1.5 core to fix a long standing > bug in the ngx_http_named_location function. > > I think we should clear out all the modules' contexts there just as in > ngx_http_internal_redirect, or we'll observe weird issues due to > left-over obsolete module contexts from the original request before > the jump. Here is a bad case in action: > http://www.ruby-forum.com/topic/2765027 > > Regards, > -agentzh > > --- nginx-1.1.5/src/http/ngx_http_core_module.c 2011-09-27 > 19:14:02.000000000 +0800 > +++ nginx-1.1.5-patched/src/http/ngx_http_core_module.c 2011-10-13 > 15:02:24.414550532 +0800 > @@ -2542,6 +2542,9 @@ > r->content_handler = NULL; > r->loc_conf = (*clcfp)->loc_conf; > > + /* clear the modules contexts */ > + ngx_memzero(r->ctx, sizeof(void *) * ngx_http_max_module); > + > ngx_http_update_location_config(r); > > cmcf = ngx_http_get_module_main_conf(r, ngx_http_core_module); Committed, thanks. Maxim Dounin From airforce.e at gmail.com Sat Oct 15 23:46:16 2011 From: airforce.e at gmail.com (Gongyuan Mao) Date: Sun, 16 Oct 2011 07:46:16 +0800 Subject: Nginx / Magento Expert In-Reply-To: References: Message-ID: Dear Megan, Yes, we have the experience of setting up some magento systems on the nginx web server. One of our client using nginx: www.herborist.com.cn If you need help please contact us and we provide the solution to tune up the system. On Sun, Oct 16, 2011 at 5:01 AM, Megan Woo wrote: > We are looking for an Nginx / Magento Expert to help us set up a > second store (multi-store in Magento). The original developer set up > some Nginx redirects that we think are causing some problems. > > Does anyone know a Nginx / Magento Expert they can recommend?? > > Thanks! > > -- > Megan Woo > Web Developer > > _______________________________________________ > nginx-devel mailing list > nginx-devel at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-devel > -- Kind Regards, Cosmo Mao ??? National System Analyst Founder & President of Solution CosmoCommerce Corporation Limited(CC Corp, Ltd) T:+86-021-66346672 M:+86-13818935123 W:CosmoCommerce.Com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sivaprasadcg at tataelxsi.co.in Mon Oct 17 04:52:18 2011 From: sivaprasadcg at tataelxsi.co.in (Sivaprasad CG) Date: Mon, 17 Oct 2011 10:22:18 +0530 Subject: error: Failed dependencies: libcrypto.so.0.9.8 is needed by nginx-1.0.5-1_WR4.1.0.0.x86_64 Message-ID: <4E9BB482.50005@tataelxsi.co.in> An HTML attachment was scrubbed... URL: From igor at sysoev.ru Mon Oct 17 08:04:25 2011 From: igor at sysoev.ru (Igor Sysoev) Date: Mon, 17 Oct 2011 12:04:25 +0400 Subject: error: Failed dependencies: libcrypto.so.0.9.8 is needed by nginx-1.0.5-1_WR4.1.0.0.x86_64 In-Reply-To: <4E9BB482.50005@tataelxsi.co.in> References: <4E9BB482.50005@tataelxsi.co.in> Message-ID: On Oct 17, 2011, at 8:52 , Sivaprasad CG wrote: > Hello, > I am trying to add nginx-1.0.5.tar.gz package to Wind River Linux. The host machine I am using is Ubuntu 10.04. > > uname -a: Linux TestMachine 2.6.32-24-generic #39-Ubuntu SMP Wed Jul 28 06:07:29 UTC 2010 i686 GNU/Linux > nginx -V: nginx: nginx version: nginx/1.0.5 nginx: built by gcc 4.4.3 (Ubuntu 4.4.3-4ubuntu5) nginx: configure arguments: --with-pcre=/home/user/workspace/Test/build/INSTALL_STAGE/pcre-7.8/../../pcre-7.8/BUILD/pcre-7.8 --with-zlib=/home/user/workspace/Test/build/INSTALL_STAGE/zlib-1.2.5/../../zlib-1.2.5/BUILD/zlib-1.2.5 > Nginx package got compiled and it created install directories and files in /usr/local/nginx folder. > But during the final creation of kernel image and RFS we are getting below error. > > Installing RPMs into filesystem directory > Preparing... ################################################## > setup ################################################## > error: Failed dependencies: > libcrypto.so.0.9.8 is needed by nginx-1.0.5-1_WR4.1.0.0.x86_64 > libcrypto.so.0.9.8(OPENSSL_0.9.8) is needed by nginx-1.0.5-1_WR4.1.0.0.x86_64 > > I got this this error after adding 'libssl-dev' package to our Ubuntu machine through apt-get. Before adding this package Wind River kernel image and RFS is created successfully. > > On analysis I found that in nginx-1.0.5\objs\ngx_auto_config.h, following addtional #defines are setting in the not working source code > #ifndef NGX_OPENSSL_MD5 > #define NGX_OPENSSL_MD5 1 > #endif > > #ifndef NGX_HAVE_OPENSSL_MD5_H > #define NGX_HAVE_OPENSSL_MD5_H 1 > #endif > > #ifndef NGX_HAVE_MD5 > #define NGX_HAVE_MD5 1 > #endif > > #ifndef NGX_HAVE_SHA1 > #define NGX_HAVE_SHA1 1 > #endif > > #ifndef NGX_HAVE_OPENSSL_SHA1_H > #define NGX_HAVE_OPENSSL_SHA1_H 1 > #endif > > Could you please tell me what could be the issue. Does nginx looks for the libssl-dev/openssl/libcrypto library versions of host machine during configuration and compilation. > Yes, nginx looks for OpenSSL library to use MD5 and SHA1 OpenSSL functions. -- Igor Sysoev http://sysoev.ru/en/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Thu Oct 20 12:36:01 2011 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 20 Oct 2011 16:36:01 +0400 Subject: [PATCH] Fixed unix ngx_write_chain_to_file() to return total bytes written Message-ID: <13566dde55124ae2d72f.1319114161@vm-bsd.mdounin.ru> # HG changeset patch # User Maxim Dounin # Date 1319074243 -14400 # Node ID 13566dde55124ae2d72f875734752cf4c7857b98 # Parent b07d81a20619e790bb0433780c58dc35ec4260ad Fixed unix ngx_write_chain_to_file() to return total bytes written. Previously result of last iteration's writev() was returned. This was unnoticed as return value was only used if chain contained only one or two buffers. diff --git a/src/os/unix/ngx_files.c b/src/os/unix/ngx_files.c --- a/src/os/unix/ngx_files.c +++ b/src/os/unix/ngx_files.c @@ -153,7 +153,7 @@ ngx_write_chain_to_file(ngx_file_t *file { u_char *prev; size_t size; - ssize_t n; + ssize_t total, n; ngx_array_t vec; struct iovec *iov, iovs[NGX_IOVS]; @@ -165,6 +165,8 @@ ngx_write_chain_to_file(ngx_file_t *file offset); } + total = 0; + vec.elts = iovs; vec.size = sizeof(struct iovec); vec.nalloc = NGX_IOVS; @@ -233,10 +235,11 @@ ngx_write_chain_to_file(ngx_file_t *file file->sys_offset += n; file->offset += n; + total += n; } while (cl); - return n; + return total; } From andre.l.caron at gmail.com Thu Oct 20 15:26:42 2011 From: andre.l.caron at gmail.com (=?UTF-8?B?QW5kcsOpIENhcm9u?=) Date: Thu, 20 Oct 2011 11:26:42 -0400 Subject: Cannot access Subversion repository Message-ID: I'm want to implement support for authentication via FastCGI authorizers. I have implemented the FastCGI wire protocol ( https://github.com/AndreLouisCaron/cfcgi) and I'm trying to write a third-party NGINX module to integrate support into the latest development version. I'm trying to access the bleeding edge version of NGinx from source. I found the SVN URL on the "install" page (http://wiki.nginx.org/Install). However, the SVN URL (svn://svn.nginx.org) seems to be dead. When checking out with Tortoise SVN, I get "No repository found in 'svn://svn.nginx.org'." Has the repository been moved somewhere else? Thanks, Andr? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Thu Oct 20 16:12:00 2011 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 20 Oct 2011 20:12:00 +0400 Subject: Cannot access Subversion repository In-Reply-To: References: Message-ID: <20111020161200.GL1911@mdounin.ru> Hello! On Thu, Oct 20, 2011 at 11:26:42AM -0400, Andr? Caron wrote: > I'm want to implement support for authentication via FastCGI authorizers. I > have implemented the FastCGI wire protocol ( > https://github.com/AndreLouisCaron/cfcgi) and I'm trying to write a > third-party NGINX module to integrate support into the latest development > version. > > I'm trying to access the bleeding edge version of NGinx from source. I > found the SVN URL on the "install" page (http://wiki.nginx.org/Install). > However, the SVN URL (svn://svn.nginx.org) seems to be dead. When checking > out with Tortoise SVN, I get "No repository found in 'svn://svn.nginx.org'." > > Has the repository been moved somewhere else? Try here: svn://svn.nginx.org/nginx Maxim Dounin From mdounin at mdounin.ru Thu Oct 20 17:41:35 2011 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 20 Oct 2011 21:41:35 +0400 Subject: [PATCH] Fixed another return in unix ngx_write_chain_to_file() Message-ID: <79c66120c46633f9f68d.1319132495@vm-bsd.mdounin.ru> # HG changeset patch # User Maxim Dounin # Date 1319132491 -14400 # Node ID 79c66120c46633f9f68d2ebb37c1a15f03f2673a # Parent 940ce296e112c04f5be28c70e42bed06f49a8793 Fixed another return in unix ngx_write_chain_to_file(). Previous patch missed special case for one iovec, it needs total bytes written to be returned as well. diff --git a/src/os/unix/ngx_files.c b/src/os/unix/ngx_files.c --- a/src/os/unix/ngx_files.c +++ b/src/os/unix/ngx_files.c @@ -204,8 +204,15 @@ ngx_write_chain_to_file(ngx_file_t *file if (vec.nelts == 1) { iov = vec.elts; - return ngx_write_file(file, (u_char *) iov[0].iov_base, - iov[0].iov_len, offset); + + n = ngx_write_file(file, (u_char *) iov[0].iov_base, + iov[0].iov_len, offset); + + if (n == NGX_ERROR) { + return n; + } + + return total + n; } if (file->sys_offset != offset) { From mdounin at mdounin.ru Fri Oct 21 09:21:17 2011 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 21 Oct 2011 13:21:17 +0400 Subject: [PATCH 0 of 2] event pipe patches Message-ID: Hello! Here are event pipe patches. First one fixes problems observed with complex protocols (FastCGI, HTTP/1.1 with chunked encoding). Second one optimizes memory and CPU usage for disk-buffered case. Note it requires ngx_write_chain_to_file() fixes posted recently. Maxim Dounin From mdounin at mdounin.ru Fri Oct 21 09:21:18 2011 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 21 Oct 2011 13:21:18 +0400 Subject: [PATCH 1 of 2] Event pipe: fixes for complex protocols In-Reply-To: References: Message-ID: <268d6673848018d7390d.1319188878@vm-bsd.mdounin.ru> # HG changeset patch # User Maxim Dounin # Date 1319132694 -14400 # Node ID 268d6673848018d7390de41b73414546da6f6463 # Parent 79c66120c46633f9f68d2ebb37c1a15f03f2673a Event pipe: fixes for complex protocols. 1. In ngx_event_pipe_write_chain_to_temp_file() make sure to fully write all shadow buffers up to last_shadow. With this change recycled buffers cannot appear in p->out anymore. This also fixes segmentation faults observed due to ngx_event_pipe_write_chain_to_temp() not freeing any raw buffers while still returning NGX_OK. 2. In ngx_event_pipe_write_to_downstream() we now properly check for busy size as a size of buffers, not a size of data in these buffers. This fixes situations where all available buffers became busy (including segmentation faults due to this). 3. The ngx_event_pipe_free_shadow_raw_buf() function is dropped. It's incorrect and not needed. diff --git a/src/event/ngx_event_pipe.c b/src/event/ngx_event_pipe.c --- a/src/event/ngx_event_pipe.c +++ b/src/event/ngx_event_pipe.c @@ -15,8 +15,6 @@ static ngx_int_t ngx_event_pipe_write_to static ngx_int_t ngx_event_pipe_write_chain_to_temp_file(ngx_event_pipe_t *p); static ngx_inline void ngx_event_pipe_remove_shadow_links(ngx_buf_t *buf); -static ngx_inline void ngx_event_pipe_free_shadow_raw_buf(ngx_chain_t **free, - ngx_buf_t *buf); static ngx_int_t ngx_event_pipe_drain_chains(ngx_event_pipe_t *p); @@ -576,17 +574,13 @@ ngx_event_pipe_write_to_downstream(ngx_e if (p->out) { cl = p->out; - if (cl->buf->recycled - && bsize + cl->buf->last - cl->buf->pos > p->busy_size) - { - flush = 1; - break; + if (cl->buf->recycled) { + ngx_log_error(NGX_LOG_ALERT, p->log, 0, + "recycled buffer in pipe out chain"); } p->out = p->out->next; - ngx_event_pipe_free_shadow_raw_buf(&p->free_raw_bufs, cl->buf); - } else if (!p->cacheable && p->in) { cl = p->in; @@ -596,24 +590,13 @@ ngx_event_pipe_write_to_downstream(ngx_e cl->buf->pos, cl->buf->last - cl->buf->pos); - if (cl->buf->recycled - && cl->buf->last_shadow - && bsize + cl->buf->last - cl->buf->pos > p->busy_size) - { - if (!prev_last_shadow) { - p->in = p->in->next; - - cl->next = NULL; - - if (out) { - *ll = cl; - } else { - out = cl; - } + if (cl->buf->recycled && prev_last_shadow) { + if (bsize + cl->buf->end - cl->buf->start > p->busy_size) { + flush = 1; + break; } - flush = 1; - break; + bsize += cl->buf->end - cl->buf->start; } prev_last_shadow = cl->buf->last_shadow; @@ -624,10 +607,6 @@ ngx_event_pipe_write_to_downstream(ngx_e break; } - if (cl->buf->recycled) { - bsize += cl->buf->last - cl->buf->pos; - } - cl->next = NULL; if (out) { @@ -703,6 +682,7 @@ ngx_event_pipe_write_chain_to_temp_file( { ssize_t size, bsize; ngx_buf_t *b; + ngx_uint_t prev_last_shadow; ngx_chain_t *cl, *tl, *next, *out, **ll, **last_free, fl; if (p->buf_to_file) { @@ -719,6 +699,7 @@ ngx_event_pipe_write_chain_to_temp_file( size = 0; cl = out; ll = NULL; + prev_last_shadow = 1; ngx_log_debug1(NGX_LOG_DEBUG_EVENT, p->log, 0, "pipe offset: %O", p->temp_file->offset); @@ -726,16 +707,21 @@ ngx_event_pipe_write_chain_to_temp_file( do { bsize = cl->buf->last - cl->buf->pos; - ngx_log_debug3(NGX_LOG_DEBUG_EVENT, p->log, 0, - "pipe buf %p, pos %p, size: %z", - cl->buf->start, cl->buf->pos, bsize); + ngx_log_debug4(NGX_LOG_DEBUG_EVENT, p->log, 0, + "pipe buf ls:%d %p, pos %p, size: %z", + cl->buf->last_shadow, cl->buf->start, + cl->buf->pos, bsize); - if ((size + bsize > p->temp_file_write_size) - || (p->temp_file->offset + size + bsize > p->max_temp_file_size)) + if (prev_last_shadow + && ((size + bsize > p->temp_file_write_size) + || (p->temp_file->offset + size + bsize + > p->max_temp_file_size))) { break; } + prev_last_shadow = cl->buf->last_shadow; + size += bsize; ll = &cl->next; cl = cl->next; @@ -913,35 +899,6 @@ ngx_event_pipe_remove_shadow_links(ngx_b } -static ngx_inline void -ngx_event_pipe_free_shadow_raw_buf(ngx_chain_t **free, ngx_buf_t *buf) -{ - ngx_buf_t *s; - ngx_chain_t *cl, **ll; - - if (buf->shadow == NULL) { - return; - } - - for (s = buf->shadow; !s->last_shadow; s = s->shadow) { /* void */ } - - ll = free; - - for (cl = *free; cl; cl = cl->next) { - if (cl->buf == s) { - *ll = cl->next; - break; - } - - if (cl->buf->shadow) { - break; - } - - ll = &cl->next; - } -} - - ngx_int_t ngx_event_pipe_add_free_buf(ngx_event_pipe_t *p, ngx_buf_t *b) { From mdounin at mdounin.ru Fri Oct 21 09:21:19 2011 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 21 Oct 2011 13:21:19 +0400 Subject: [PATCH 2 of 2] Event pipe: reduced number of file buffers used In-Reply-To: References: Message-ID: <761bf79b5415190ed29a.1319188879@vm-bsd.mdounin.ru> # HG changeset patch # User Maxim Dounin # Date 1319187535 -14400 # Node ID 761bf79b5415190ed29a89b4197f6b7ca33ea2e0 # Parent 268d6673848018d7390de41b73414546da6f6463 Event pipe: reduced number of file buffers used. If possible we now just extend already present file buffer in p->out chain instead of keeping ngx_buf_t for each buffer we've flushed to disk. This saves about 120 bytes of memory per buffer flushed to disk, and resolves high CPU usage observed in edge cases (due to coalescing these buffers on send). diff --git a/src/event/ngx_event_pipe.c b/src/event/ngx_event_pipe.c --- a/src/event/ngx_event_pipe.c +++ b/src/event/ngx_event_pipe.c @@ -680,10 +680,10 @@ ngx_event_pipe_write_to_downstream(ngx_e static ngx_int_t ngx_event_pipe_write_chain_to_temp_file(ngx_event_pipe_t *p) { - ssize_t size, bsize; + ssize_t size, bsize, n; ngx_buf_t *b; ngx_uint_t prev_last_shadow; - ngx_chain_t *cl, *tl, *next, *out, **ll, **last_free, fl; + ngx_chain_t *cl, *tl, *next, *out, **ll, **last_out, **last_free, fl; if (p->buf_to_file) { fl.buf = p->buf_to_file; @@ -748,10 +748,63 @@ ngx_event_pipe_write_chain_to_temp_file( p->last_in = &p->in; } - if (ngx_write_chain_to_temp_file(p->temp_file, out) == NGX_ERROR) { + n = ngx_write_chain_to_temp_file(p->temp_file, out); + + if (n == NGX_ERROR) { return NGX_ABORT; } + if (p->buf_to_file) { + p->temp_file->offset = p->buf_to_file->last - p->buf_to_file->pos; + n -= p->buf_to_file->last - p->buf_to_file->pos; + p->buf_to_file = NULL; + out = out->next; + } + + if (n > 0) { + /* update previous buffer or add new buffer */ + + if (p->out) { + for (cl = p->out; cl->next; cl = cl->next) { /* void */ } + + b = cl->buf; + + if (b->file_last == p->temp_file->offset) { + p->temp_file->offset += n; + b->file_last = p->temp_file->offset; + goto free; + } + + last_out = &cl->next; + + } else { + last_out = &p->out; + } + + cl = ngx_chain_get_free_buf(p->pool, &p->free); + if (cl == NULL) { + return NGX_ABORT; + } + + b = cl->buf; + + ngx_memzero(b, sizeof(ngx_buf_t)); + + b->tag = p->tag; + + b->file = &p->temp_file->file; + b->file_pos = p->temp_file->offset; + p->temp_file->offset += n; + b->file_last = p->temp_file->offset; + + b->in_file = 1; + b->temp_file = 1; + + *last_out = cl; + } + +free: + for (last_free = &p->free_raw_bufs; *last_free != NULL; last_free = &(*last_free)->next) @@ -759,31 +812,13 @@ ngx_event_pipe_write_chain_to_temp_file( /* void */ } - if (p->buf_to_file) { - p->temp_file->offset = p->buf_to_file->last - p->buf_to_file->pos; - p->buf_to_file = NULL; - out = out->next; - } - for (cl = out; cl; cl = next) { next = cl->next; - cl->next = NULL; + + cl->next = p->free; + p->free = cl; b = cl->buf; - b->file = &p->temp_file->file; - b->file_pos = p->temp_file->offset; - p->temp_file->offset += b->last - b->pos; - b->file_last = p->temp_file->offset; - - b->in_file = 1; - b->temp_file = 1; - - if (p->out) { - *p->last_out = cl; - } else { - p->out = cl; - } - p->last_out = &cl->next; if (b->last_shadow) { diff --git a/src/event/ngx_event_pipe.h b/src/event/ngx_event_pipe.h --- a/src/event/ngx_event_pipe.h +++ b/src/event/ngx_event_pipe.h @@ -30,8 +30,6 @@ struct ngx_event_pipe_s { ngx_chain_t **last_in; ngx_chain_t *out; - ngx_chain_t **last_out; - ngx_chain_t *free; ngx_chain_t *busy; From andre.l.caron at gmail.com Fri Oct 21 13:30:21 2011 From: andre.l.caron at gmail.com (=?UTF-8?B?QW5kcsOpIENhcm9u?=) Date: Fri, 21 Oct 2011 09:30:21 -0400 Subject: Cannot access subversion repository Message-ID: > Try here: > svn://svn.nginx.org/nginx > Maxim Dounin Works like a charm, thanks. It might be a good idea for someone with appropriate authorization to update the "Install" page on the wiki. ?Wanting to update the wiki, I created an account, but I could not edit the page, so I checked out the "Install:Talk" page. ?It seems the "Install" page is not publicly editable (with good reason) and that I should leave a comment on the discussion hoping someone will notice, but I can't leave a comment either... Andr? From andre.l.caron at gmail.com Fri Oct 21 13:46:45 2011 From: andre.l.caron at gmail.com (=?UTF-8?B?QW5kcsOpIENhcm9u?=) Date: Fri, 21 Oct 2011 09:46:45 -0400 Subject: Cannot access subversion repository Message-ID: > Try here: > svn://svn.nginx.org/nginx > Maxim Dounin Works like a charm, thanks. It might be a good idea for someone to update the "Install" page on the wiki. Andr? -------------- next part -------------- An HTML attachment was scrubbed... URL: From zzz at zzz.org.ua Fri Oct 21 17:58:12 2011 From: zzz at zzz.org.ua (Alexandr Gomoliako) Date: Fri, 21 Oct 2011 20:58:12 +0300 Subject: [ANN] ngx_trace - runtime call tracer for nginx Message-ID: Hi guys, I just published a simple tool on github that helps with module development and learning internals a bit. Here is a sample output it can generate: ngx_process_events_and_timers ngx_event_find_timer ngx_epoll_process_events ngx_event_accept ngx_http_init_connection ngx_handle_read_event ngx_epoll_add_event ngx_event_expire_timers ngx_process_events_and_timers ngx_event_find_timer ngx_epoll_process_events ngx_http_init_request ngx_http_process_request_line ngx_http_read_request_header github link: https://github.com/zzzcpan/ngx_trace From maxim at nginx.com Mon Oct 24 10:24:44 2011 From: maxim at nginx.com (Maxim Konovalov) Date: Mon, 24 Oct 2011 14:24:44 +0400 Subject: svn commit logs will go to the list Message-ID: <4EA53CEC.9080909@nginx.com> Hello, just a heads-up: we are going to push svn commit logs to nginx-devel@ in order to increase awareness of the community on what is going on. So, please expect more traffic in the list and tune your filters accordingly. -- Maxim Konovalov +7 (910) 4293178 http://nginx.com/ From mp3geek at gmail.com Mon Oct 24 12:38:25 2011 From: mp3geek at gmail.com (Ryan Brown) Date: Tue, 25 Oct 2011 01:38:25 +1300 Subject: svn commit logs will go to the list In-Reply-To: <4EA53CEC.9080909@nginx.com> References: <4EA53CEC.9080909@nginx.com> Message-ID: Hi, Has there been any reason to keep svn and not go with git or hg? On Mon, Oct 24, 2011 at 11:24 PM, Maxim Konovalov wrote: > Hello, > > just a heads-up: we are going to push svn commit logs to nginx-devel@ in > order to increase awareness of the community on what is going on. ?So, > please expect more traffic in the list and tune your filters accordingly. > From igor at sysoev.ru Mon Oct 24 12:45:17 2011 From: igor at sysoev.ru (Igor Sysoev) Date: Mon, 24 Oct 2011 16:45:17 +0400 Subject: svn commit logs will go to the list In-Reply-To: References: <4EA53CEC.9080909@nginx.com> Message-ID: <20111024124517.GC81284@nginx.com> On Tue, Oct 25, 2011 at 01:38:25AM +1300, Ryan Brown wrote: > Has there been any reason to keep svn and not go with git or hg? We will probably use hg, but not right now. -- Igor Sysoev From catap at catap.ru Mon Oct 24 12:57:14 2011 From: catap at catap.ru (Kirill A. Korinskiy) Date: Mon, 24 Oct 2011 16:57:14 +0400 Subject: svn commit logs will go to the list In-Reply-To: <20111024124517.GC81284@nginx.com> References: <4EA53CEC.9080909@nginx.com> <20111024124517.GC81284@nginx.com> Message-ID: On Mon, Oct 24, 2011 at 16:45, Igor Sysoev wrote: > On Tue, Oct 25, 2011 at 01:38:25AM +1300, Ryan Brown wrote: > > > Has there been any reason to keep svn and not go with git or hg? > > We will probably use hg, but not right now. > > Why not git and github? -- wbr, Kirill -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at nginx.com Mon Oct 24 12:59:03 2011 From: noreply at nginx.com (noreply at nginx.com) Date: Mon, 24 Oct 2011 12:59:03 +0000 Subject: [nginx] svn commit: r4223 - trunk/src/core Message-ID: Author: is Date: 2011-10-24 12:59:01 +0000 (Mon, 24 Oct 2011) New Revision: 4223 Modified: trunk/src/core/nginx.c Log: FreeBSD's MALLOC_OPTIONS must be set before any malloc() call. The bug has been introduced in r3799. Modified: trunk/src/core/nginx.c =================================================================== --- trunk/src/core/nginx.c 2011-10-21 11:04:46 UTC (rev 4222) +++ trunk/src/core/nginx.c 2011-10-24 12:59:01 UTC (rev 4223) @@ -203,6 +203,10 @@ ngx_cycle_t *cycle, init_cycle; ngx_core_conf_t *ccf; +#if (NGX_FREEBSD) + ngx_debug_init(); +#endif + if (ngx_strerror_init() != NGX_OK) { return 1; } @@ -260,10 +264,6 @@ } } -#if (NGX_FREEBSD) - ngx_debug_init(); -#endif - /* TODO */ ngx_max_sockets = -1; ngx_time_init(); From mdounin at mdounin.ru Mon Oct 24 13:43:57 2011 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 24 Oct 2011 17:43:57 +0400 Subject: svn commit logs will go to the list In-Reply-To: References: <4EA53CEC.9080909@nginx.com> <20111024124517.GC81284@nginx.com> Message-ID: <20111024134357.GT62535@mdounin.ru> Hello! On Mon, Oct 24, 2011 at 04:57:14PM +0400, Kirill A. Korinskiy wrote: > On Mon, Oct 24, 2011 at 16:45, Igor Sysoev wrote: > > > On Tue, Oct 25, 2011 at 01:38:25AM +1300, Ryan Brown wrote: > > > > > Has there been any reason to keep svn and not go with git or hg? > > > > We will probably use hg, but not right now. > > > > > Why not git and github? Well, I guess you actually know the answer. ;) Maxim Dounin From catap at catap.ru Mon Oct 24 13:56:38 2011 From: catap at catap.ru (Kirill A. Korinskiy) Date: Mon, 24 Oct 2011 17:56:38 +0400 Subject: svn commit logs will go to the list In-Reply-To: <20111024134357.GT62535@mdounin.ru> References: <4EA53CEC.9080909@nginx.com> <20111024124517.GC81284@nginx.com> <20111024134357.GT62535@mdounin.ru> Message-ID: On Mon, Oct 24, 2011 at 17:43, Maxim Dounin wrote: > Hello! > > On Mon, Oct 24, 2011 at 04:57:14PM +0400, Kirill A. Korinskiy wrote: > > > On Mon, Oct 24, 2011 at 16:45, Igor Sysoev wrote: > > > > > On Tue, Oct 25, 2011 at 01:38:25AM +1300, Ryan Brown wrote: > > > > > > > Has there been any reason to keep svn and not go with git or hg? > > > > > > We will probably use hg, but not right now. > > > > > > > > Why not git and github? > > Well, I guess you actually know the answer. ;) > Yeah. Anyway I know about too http://hg-git.github.com/ -- wbr, Kirill -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor at sysoev.ru Mon Oct 24 15:46:49 2011 From: igor at sysoev.ru (igor at sysoev.ru) Date: Mon, 24 Oct 2011 15:46:49 +0000 Subject: [nginx] svn commit: r4224 - in trunk/src: core os/unix os/win32 Message-ID: Author: is Date: 2011-10-24 15:46:48 +0000 (Mon, 24 Oct 2011) New Revision: 4224 Modified: trunk/src/core/nginx.c trunk/src/core/ngx_slab.c trunk/src/os/unix/ngx_darwin.h trunk/src/os/unix/ngx_darwin_config.h trunk/src/os/unix/ngx_darwin_init.c trunk/src/os/unix/ngx_freebsd.h trunk/src/os/unix/ngx_freebsd_config.h trunk/src/os/unix/ngx_freebsd_init.c trunk/src/os/unix/ngx_linux_config.h trunk/src/os/unix/ngx_os.h trunk/src/os/unix/ngx_posix_config.h trunk/src/os/unix/ngx_solaris_config.h trunk/src/os/win32/ngx_win32_config.h Log: malloc() debugging on MacOSX. Modified: trunk/src/core/nginx.c =================================================================== --- trunk/src/core/nginx.c 2011-10-24 12:59:01 UTC (rev 4223) +++ trunk/src/core/nginx.c 2011-10-24 15:46:48 UTC (rev 4224) @@ -203,9 +203,7 @@ ngx_cycle_t *cycle, init_cycle; ngx_core_conf_t *ccf; -#if (NGX_FREEBSD) ngx_debug_init(); -#endif if (ngx_strerror_init() != NGX_OK) { return 1; Modified: trunk/src/core/ngx_slab.c =================================================================== --- trunk/src/core/ngx_slab.c 2011-10-24 12:59:01 UTC (rev 4223) +++ trunk/src/core/ngx_slab.c 2011-10-24 15:46:48 UTC (rev 4224) @@ -46,10 +46,10 @@ #else -#if (NGX_FREEBSD) +#if (NGX_HAVE_DEBUG_MALLOC) #define ngx_slab_junk(p, size) \ - if (ngx_freebsd_debug_malloc) ngx_memset(p, 0xD0, size) + if (ngx_debug_malloc) ngx_memset(p, 0xD0, size) #else Modified: trunk/src/os/unix/ngx_darwin.h =================================================================== --- trunk/src/os/unix/ngx_darwin.h 2011-10-24 12:59:01 UTC (rev 4223) +++ trunk/src/os/unix/ngx_darwin.h 2011-10-24 15:46:48 UTC (rev 4224) @@ -8,6 +8,7 @@ #define _NGX_DARWIN_H_INCLUDED_ +void ngx_debug_init(void); ngx_chain_t *ngx_darwin_sendfile_chain(ngx_connection_t *c, ngx_chain_t *in, off_t limit); @@ -15,5 +16,7 @@ extern int ngx_darwin_hw_ncpu; extern u_long ngx_darwin_net_inet_tcp_sendspace; +extern ngx_uint_t ngx_debug_malloc; + #endif /* _NGX_DARWIN_H_INCLUDED_ */ Modified: trunk/src/os/unix/ngx_darwin_config.h =================================================================== --- trunk/src/os/unix/ngx_darwin_config.h 2011-10-24 12:59:01 UTC (rev 4223) +++ trunk/src/os/unix/ngx_darwin_config.h 2011-10-24 15:46:48 UTC (rev 4224) @@ -87,6 +87,7 @@ #define NGX_HAVE_OS_SPECIFIC_INIT 1 +#define NGX_HAVE_DEBUG_MALLOC 1 extern char **environ; Modified: trunk/src/os/unix/ngx_darwin_init.c =================================================================== --- trunk/src/os/unix/ngx_darwin_init.c 2011-10-24 12:59:01 UTC (rev 4223) +++ trunk/src/os/unix/ngx_darwin_init.c 2011-10-24 15:46:48 UTC (rev 4224) @@ -14,7 +14,9 @@ int ngx_darwin_kern_ipc_somaxconn; u_long ngx_darwin_net_inet_tcp_sendspace; +ngx_uint_t ngx_debug_malloc; + static ngx_os_io_t ngx_darwin_io = { ngx_unix_recv, ngx_readv_chain, @@ -55,6 +57,34 @@ }; +void +ngx_debug_init() +{ +#if (NGX_DEBUG_MALLOC) + + /* + * MacOSX 10.6, 10.7: MallocScribble fills freed memory with 0x55 + * and fills allocated memory with 0xAA. + * MacOSX 10.4, 10.5: MallocScribble fills freed memory with 0x55, + * MallocPreScribble fills allocated memory with 0xAA. + * MacOSX 10.3: MallocScribble fills freed memory with 0x55, + * and no way to fill allocated memory. + */ + + setenv("MallocScribble", "1", 0); + + ngx_debug_malloc = 1; + +#else + + if (getenv("MallocScribble")) { + ngx_debug_malloc = 1; + } + +#endif +} + + ngx_int_t ngx_os_specific_init(ngx_log_t *log) { Modified: trunk/src/os/unix/ngx_freebsd.h =================================================================== --- trunk/src/os/unix/ngx_freebsd.h 2011-10-24 12:59:01 UTC (rev 4223) +++ trunk/src/os/unix/ngx_freebsd.h 2011-10-24 15:46:48 UTC (rev 4224) @@ -8,6 +8,7 @@ #define _NGX_FREEBSD_H_INCLUDED_ +void ngx_debug_init(void); ngx_chain_t *ngx_freebsd_sendfile_chain(ngx_connection_t *c, ngx_chain_t *in, off_t limit); @@ -17,7 +18,7 @@ extern ngx_uint_t ngx_freebsd_sendfile_nbytes_bug; extern ngx_uint_t ngx_freebsd_use_tcp_nopush; -extern ngx_uint_t ngx_freebsd_debug_malloc; +extern ngx_uint_t ngx_debug_malloc; #endif /* _NGX_FREEBSD_H_INCLUDED_ */ Modified: trunk/src/os/unix/ngx_freebsd_config.h =================================================================== --- trunk/src/os/unix/ngx_freebsd_config.h 2011-10-24 12:59:01 UTC (rev 4223) +++ trunk/src/os/unix/ngx_freebsd_config.h 2011-10-24 15:46:48 UTC (rev 4224) @@ -109,6 +109,7 @@ #define NGX_HAVE_OS_SPECIFIC_INIT 1 +#define NGX_HAVE_DEBUG_MALLOC 1 extern char **environ; Modified: trunk/src/os/unix/ngx_freebsd_init.c =================================================================== --- trunk/src/os/unix/ngx_freebsd_init.c 2011-10-24 12:59:01 UTC (rev 4223) +++ trunk/src/os/unix/ngx_freebsd_init.c 2011-10-24 15:46:48 UTC (rev 4224) @@ -22,9 +22,10 @@ ngx_uint_t ngx_freebsd_sendfile_nbytes_bug; ngx_uint_t ngx_freebsd_use_tcp_nopush; -ngx_uint_t ngx_freebsd_debug_malloc; +ngx_uint_t ngx_debug_malloc; + static ngx_os_io_t ngx_freebsd_io = { ngx_unix_recv, ngx_readv_chain, @@ -80,7 +81,7 @@ malloc_options = "J"; #endif - ngx_freebsd_debug_malloc = 1; + ngx_debug_malloc = 1; #else char *mo; @@ -88,7 +89,7 @@ mo = getenv("MALLOC_OPTIONS"); if (mo && ngx_strchr(mo, 'J')) { - ngx_freebsd_debug_malloc = 1; + ngx_debug_malloc = 1; } #endif } Modified: trunk/src/os/unix/ngx_linux_config.h =================================================================== --- trunk/src/os/unix/ngx_linux_config.h 2011-10-24 12:59:01 UTC (rev 4223) +++ trunk/src/os/unix/ngx_linux_config.h 2011-10-24 15:46:48 UTC (rev 4224) @@ -108,6 +108,7 @@ #define NGX_HAVE_OS_SPECIFIC_INIT 1 +#define ngx_debug_init() extern char **environ; Modified: trunk/src/os/unix/ngx_os.h =================================================================== --- trunk/src/os/unix/ngx_os.h 2011-10-24 12:59:01 UTC (rev 4223) +++ trunk/src/os/unix/ngx_os.h 2011-10-24 15:46:48 UTC (rev 4224) @@ -31,7 +31,6 @@ } ngx_os_io_t; -void ngx_debug_init(void); ngx_int_t ngx_os_init(ngx_log_t *log); void ngx_os_status(ngx_log_t *log); ngx_int_t ngx_os_specific_init(ngx_log_t *log); Modified: trunk/src/os/unix/ngx_posix_config.h =================================================================== --- trunk/src/os/unix/ngx_posix_config.h 2011-10-24 12:59:01 UTC (rev 4223) +++ trunk/src/os/unix/ngx_posix_config.h 2011-10-24 15:46:48 UTC (rev 4224) @@ -125,7 +125,9 @@ #define NGX_LISTEN_BACKLOG 511 +#define ngx_debug_init() + #if (__FreeBSD__) && (__FreeBSD_version < 400017) #include /* ALIGN() */ Modified: trunk/src/os/unix/ngx_solaris_config.h =================================================================== --- trunk/src/os/unix/ngx_solaris_config.h 2011-10-24 12:59:01 UTC (rev 4223) +++ trunk/src/os/unix/ngx_solaris_config.h 2011-10-24 15:46:48 UTC (rev 4224) @@ -98,6 +98,7 @@ #define NGX_HAVE_OS_SPECIFIC_INIT 1 +#define ngx_debug_init() extern char **environ; Modified: trunk/src/os/win32/ngx_win32_config.h =================================================================== --- trunk/src/os/win32/ngx_win32_config.h 2011-10-24 12:59:01 UTC (rev 4223) +++ trunk/src/os/win32/ngx_win32_config.h 2011-10-24 15:46:48 UTC (rev 4224) @@ -182,6 +182,7 @@ #define ngx_random rand +#define ngx_debug_init() #endif /* _NGX_WIN32_CONFIG_H_INCLUDED_ */ From igor at sysoev.ru Mon Oct 24 15:50:20 2011 From: igor at sysoev.ru (igor at sysoev.ru) Date: Mon, 24 Oct 2011 15:50:20 +0000 Subject: [nginx] svn commit: r4225 - trunk/src/core Message-ID: Author: is Date: 2011-10-24 15:50:19 +0000 (Mon, 24 Oct 2011) New Revision: 4225 Modified: trunk/src/core/ngx_slab.c Log: Using of junk value in slab allocator similar to modern FreeBSD values. Modified: trunk/src/core/ngx_slab.c =================================================================== --- trunk/src/core/ngx_slab.c 2011-10-24 15:46:48 UTC (rev 4224) +++ trunk/src/core/ngx_slab.c 2011-10-24 15:50:19 UTC (rev 4225) @@ -42,14 +42,14 @@ #if (NGX_DEBUG_MALLOC) -#define ngx_slab_junk(p, size) ngx_memset(p, 0xD0, size) +#define ngx_slab_junk(p, size) ngx_memset(p, 0xA5, size) #else #if (NGX_HAVE_DEBUG_MALLOC) #define ngx_slab_junk(p, size) \ - if (ngx_debug_malloc) ngx_memset(p, 0xD0, size) + if (ngx_debug_malloc) ngx_memset(p, 0xA5, size) #else From igor at sysoev.ru Mon Oct 24 16:09:05 2011 From: igor at sysoev.ru (igor at sysoev.ru) Date: Mon, 24 Oct 2011 16:09:05 +0000 Subject: [nginx] svn commit: r4226 - in trunk/src: core http mail Message-ID: Author: is Date: 2011-10-24 16:09:05 +0000 (Mon, 24 Oct 2011) New Revision: 4226 Modified: trunk/src/core/ngx_resolver.c trunk/src/core/ngx_resolver.h trunk/src/http/ngx_http_core_module.c trunk/src/mail/ngx_mail_core_module.c Log: Support of several resolvers. Patch by Kirill A. Korinskiy. Modified: trunk/src/core/ngx_resolver.c =================================================================== --- trunk/src/core/ngx_resolver.c 2011-10-24 15:50:19 UTC (rev 4225) +++ trunk/src/core/ngx_resolver.c 2011-10-24 16:09:05 UTC (rev 4226) @@ -91,8 +91,10 @@ ngx_resolver_t * -ngx_resolver_create(ngx_conf_t *cf, ngx_addr_t *addr) +ngx_resolver_create(ngx_conf_t *cf, ngx_str_t *names, ngx_uint_t n) { + ngx_url_t u; + ngx_uint_t i; ngx_resolver_t *r; ngx_pool_cleanup_t *cln; ngx_udp_connection_t *uc; @@ -109,6 +111,15 @@ return NULL; } + if (n) { + if (ngx_array_init(&r->udp_connections, cf->pool, n, + sizeof(ngx_udp_connection_t)) + != NGX_OK) + { + return NULL; + } + } + cln->data = r; r->event = ngx_calloc(sizeof(ngx_event_t), cf->log); @@ -140,17 +151,27 @@ r->log = &cf->cycle->new_log; r->log_level = NGX_LOG_ERR; - if (addr) { - uc = ngx_calloc(sizeof(ngx_udp_connection_t), cf->log); + for (i = 0; i < n; i++) { + ngx_memzero(&u, sizeof(ngx_url_t)); + + u.host = names[i]; + u.port = 53; + + if (ngx_inet_resolve_host(cf->pool, &u) != NGX_OK) { + ngx_conf_log_error(NGX_LOG_EMERG, cf, 0, "%V: %s", &u.host, u.err); + return NULL; + } + + uc = ngx_array_push(&r->udp_connections); if (uc == NULL) { return NULL; } - r->udp_connection = uc; + ngx_memzero(uc, sizeof(ngx_udp_connection_t)); - uc->sockaddr = addr->sockaddr; - uc->socklen = addr->socklen; - uc->server = addr->name; + uc->sockaddr = u.addrs->sockaddr; + uc->socklen = u.addrs->socklen; + uc->server = u.addrs->name; uc->log = cf->cycle->new_log; uc->log.handler = ngx_resolver_log_error; @@ -167,6 +188,9 @@ { ngx_resolver_t *r = data; + ngx_uint_t i; + ngx_udp_connection_t *uc; + if (r) { ngx_log_debug0(NGX_LOG_DEBUG_CORE, ngx_cycle->log, 0, "cleanup resolver"); @@ -179,12 +203,13 @@ ngx_free(r->event); } - if (r->udp_connection) { - if (r->udp_connection->connection) { - ngx_close_connection(r->udp_connection->connection); + + uc = r->udp_connections.elts; + + for (i = 0; i < r->udp_connections.nelts; i++) { + if (uc[i].connection) { + ngx_close_connection(uc[i].connection); } - - ngx_free(r->udp_connection); } ngx_free(r); @@ -242,7 +267,7 @@ } } - if (r->udp_connection == NULL) { + if (r->udp_connections.nelts == 0) { return NGX_NO_RESOLVER; } @@ -826,8 +851,13 @@ ssize_t n; ngx_udp_connection_t *uc; - uc = r->udp_connection; + uc = r->udp_connections.elts; + uc = &uc[r->last_connection++]; + if (r->last_connection == r->udp_connections.nelts) { + r->last_connection = 0; + } + if (uc->connection == NULL) { if (ngx_udp_connect(uc) != NGX_OK) { return NGX_ERROR; Modified: trunk/src/core/ngx_resolver.h =================================================================== --- trunk/src/core/ngx_resolver.h 2011-10-24 15:50:19 UTC (rev 4225) +++ trunk/src/core/ngx_resolver.h 2011-10-24 16:09:05 UTC (rev 4226) @@ -77,16 +77,16 @@ typedef struct { /* has to be pointer because of "incomplete type" */ ngx_event_t *event; - - /* TODO: DNS peers balancer */ - /* STUB */ - ngx_udp_connection_t *udp_connection; - + void *dummy; ngx_log_t *log; /* ident must be after 3 pointers */ ngx_int_t ident; + /* simple round robin DNS peers balancer */ + ngx_array_t udp_connections; + ngx_uint_t last_connection; + ngx_rbtree_t name_rbtree; ngx_rbtree_node_t name_sentinel; @@ -123,8 +123,6 @@ in_addr_t *addrs; in_addr_t addr; - /* TODO: DNS peers balancer ctx */ - ngx_resolver_handler_pt handler; void *data; ngx_msec_t timeout; @@ -135,7 +133,8 @@ }; -ngx_resolver_t *ngx_resolver_create(ngx_conf_t *cf, ngx_addr_t *addr); +ngx_resolver_t *ngx_resolver_create(ngx_conf_t *cf, ngx_str_t *names, + ngx_uint_t n); ngx_resolver_ctx_t *ngx_resolve_start(ngx_resolver_t *r, ngx_resolver_ctx_t *temp); ngx_int_t ngx_resolve_name(ngx_resolver_ctx_t *ctx); Modified: trunk/src/http/ngx_http_core_module.c =================================================================== --- trunk/src/http/ngx_http_core_module.c 2011-10-24 15:50:19 UTC (rev 4225) +++ trunk/src/http/ngx_http_core_module.c 2011-10-24 16:09:05 UTC (rev 4226) @@ -718,7 +718,7 @@ NULL }, { ngx_string("resolver"), - NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|NGX_CONF_TAKE1, + NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|NGX_CONF_1MORE, ngx_http_core_resolver, NGX_HTTP_LOC_CONF_OFFSET, 0, @@ -3535,7 +3535,7 @@ * to inherit it in all servers */ - prev->resolver = ngx_resolver_create(cf, NULL); + prev->resolver = ngx_resolver_create(cf, NULL, 0); if (prev->resolver == NULL) { return NGX_CONF_ERROR; } @@ -4540,7 +4540,6 @@ { ngx_http_core_loc_conf_t *clcf = conf; - ngx_url_t u; ngx_str_t *value; if (clcf->resolver) { @@ -4549,21 +4548,11 @@ value = cf->args->elts; - ngx_memzero(&u, sizeof(ngx_url_t)); - - u.host = value[1]; - u.port = 53; - - if (ngx_inet_resolve_host(cf->pool, &u) != NGX_OK) { - ngx_conf_log_error(NGX_LOG_EMERG, cf, 0, "%V: %s", &u.host, u.err); + clcf->resolver = ngx_resolver_create(cf, &value[1], cf->args->nelts - 1); + if (clcf->resolver == NULL) { return NGX_CONF_ERROR; } - clcf->resolver = ngx_resolver_create(cf, &u.addrs[0]); - if (clcf->resolver == NULL) { - return NGX_OK; - } - return NGX_CONF_OK; } Modified: trunk/src/mail/ngx_mail_core_module.c =================================================================== --- trunk/src/mail/ngx_mail_core_module.c 2011-10-24 15:50:19 UTC (rev 4225) +++ trunk/src/mail/ngx_mail_core_module.c 2011-10-24 16:09:05 UTC (rev 4226) @@ -69,7 +69,7 @@ NULL }, { ngx_string("resolver"), - NGX_MAIL_MAIN_CONF|NGX_MAIL_SRV_CONF|NGX_CONF_TAKE1, + NGX_MAIL_MAIN_CONF|NGX_MAIL_SRV_CONF|NGX_CONF_1MORE, ngx_mail_core_resolver, NGX_MAIL_SRV_CONF_OFFSET, 0, @@ -493,7 +493,6 @@ { ngx_mail_core_srv_conf_t *cscf = conf; - ngx_url_t u; ngx_str_t *value; value = cf->args->elts; @@ -507,21 +506,11 @@ return NGX_CONF_OK; } - ngx_memzero(&u, sizeof(ngx_url_t)); - - u.host = value[1]; - u.port = 53; - - if (ngx_inet_resolve_host(cf->pool, &u) != NGX_OK) { - ngx_conf_log_error(NGX_LOG_EMERG, cf, 0, "%V: %s", &u.host, u.err); + cscf->resolver = ngx_resolver_create(cf, &value[1], cf->args->nelts - 1); + if (cscf->resolver == NULL) { return NGX_CONF_ERROR; } - cscf->resolver = ngx_resolver_create(cf, &u.addrs[0]); - if (cscf->resolver == NULL) { - return NGX_CONF_OK; - } - return NGX_CONF_OK; } From appa at perusio.net Mon Oct 24 23:29:31 2011 From: appa at perusio.net (=?UTF-8?B?QW50w7NuaW8=?= P. P. Almeida) Date: Tue, 25 Oct 2011 00:29:31 +0100 Subject: svn commit logs will go to the list In-Reply-To: <20111024134357.GT62535@mdounin.ru> References: <4EA53CEC.9080909@nginx.com> <20111024124517.GC81284@nginx.com> <20111024134357.GT62535@mdounin.ru> Message-ID: <8739eiufxg.wl%appa@perusio.net> On 24 Out 2011 14h43 WEST, mdounin at mdounin.ru wrote: > Hello! > > On Mon, Oct 24, 2011 at 04:57:14PM +0400, Kirill A. Korinskiy wrote: > >> On Mon, Oct 24, 2011 at 16:45, Igor Sysoev wrote: >> >>> On Tue, Oct 25, 2011 at 01:38:25AM +1300, Ryan Brown wrote: >>> >>>> Has there been any reason to keep svn and not go with git or hg? >>> >>> We will probably use hg, but not right now. >>> >>> >> Why not git and github? > > Well, I guess you actually know the answer. ;) At the risk at stepping in a conversation which I lack the full context. If you're partial do Mercurial you could use bitbucket.org. Now supports also git and private repos. The interface is a few notches below the github interface but many above SVN and Trac IMHO. Just a suggestion. --- appa From zzz at zzz.org.ua Tue Oct 25 00:54:02 2011 From: zzz at zzz.org.ua (Alexandr Gomoliako) Date: Tue, 25 Oct 2011 03:54:02 +0300 Subject: svn commit logs will go to the list In-Reply-To: <8739eiufxg.wl%appa@perusio.net> References: <4EA53CEC.9080909@nginx.com> <20111024124517.GC81284@nginx.com> <20111024134357.GT62535@mdounin.ru> <8739eiufxg.wl%appa@perusio.net> Message-ID: On Tue, Oct 25, 2011 at 2:29 AM, Ant?nio P. P. Almeida wrote: >>>>> Has there been any reason to keep svn and not go with git or hg? >>>> We will probably use hg, but not right now. >>> Why not git and github? >> Well, I guess you actually know the answer. ;) > At the risk at stepping in a conversation which I lack the full > context. If you're partial do Mercurial you could use > bitbucket.org. Now supports also git and private repos. The interface > is a few notches below the github interface but many above SVN and > Trac IMHO. I think the whole story was about mercurial being better than git. But it was quite some time ago, things are different now. Github is obviously very important. I'm still using mercurial though, it's hard to get used to git after years with hg. From igor at sysoev.ru Tue Oct 25 15:04:10 2011 From: igor at sysoev.ru (igor at sysoev.ru) Date: Tue, 25 Oct 2011 15:04:10 +0000 Subject: [nginx] svn commit: r4229 - trunk/src/event Message-ID: Author: is Date: 2011-10-25 15:04:09 +0000 (Tue, 25 Oct 2011) New Revision: 4229 Modified: trunk/src/event/ngx_event_openssl.c Log: Decrease of log level of some SSL handshake errors. Modified: trunk/src/event/ngx_event_openssl.c =================================================================== --- trunk/src/event/ngx_event_openssl.c 2011-10-25 13:48:43 UTC (rev 4228) +++ trunk/src/event/ngx_event_openssl.c 2011-10-25 15:04:09 UTC (rev 4229) @@ -1352,19 +1352,37 @@ n = ERR_GET_REASON(ERR_peek_error()); /* handshake failures */ - if (n == SSL_R_BLOCK_CIPHER_PAD_IS_WRONG /* 129 */ + if (n == SSL_R_BAD_CHANGE_CIPHER_SPEC /* 103 */ + || n == SSL_R_BLOCK_CIPHER_PAD_IS_WRONG /* 129 */ || n == SSL_R_DIGEST_CHECK_FAILED /* 149 */ + || n == SSL_R_ERROR_IN_RECEIVED_CIPHER_LIST /* 151 */ + || n == SSL_R_EXCESSIVE_MESSAGE_SIZE /* 152 */ || n == SSL_R_LENGTH_MISMATCH /* 159 */ || n == SSL_R_NO_CIPHERS_PASSED /* 182 */ || n == SSL_R_NO_CIPHERS_SPECIFIED /* 183 */ + || n == SSL_R_NO_COMPRESSION_SPECIFIED /* 187 */ || n == SSL_R_NO_SHARED_CIPHER /* 193 */ || n == SSL_R_RECORD_LENGTH_MISMATCH /* 213 */ +#ifdef SSL_R_PARSE_TLSEXT + || n == SSL_R_PARSE_TLSEXT /* 227 */ +#endif || n == SSL_R_UNEXPECTED_MESSAGE /* 244 */ || n == SSL_R_UNEXPECTED_RECORD /* 245 */ || n == SSL_R_UNKNOWN_ALERT_TYPE /* 246 */ || n == SSL_R_UNKNOWN_PROTOCOL /* 252 */ || n == SSL_R_WRONG_VERSION_NUMBER /* 267 */ || n == SSL_R_DECRYPTION_FAILED_OR_BAD_RECORD_MAC /* 281 */ +#ifdef SSL_R_RENEGOTIATE_EXT_TOO_LONG + || n == SSL_R_RENEGOTIATE_EXT_TOO_LONG /* 335 */ + || n == SSL_R_RENEGOTIATION_ENCODING_ERR /* 336 */ + || n == SSL_R_RENEGOTIATION_MISMATCH /* 337 */ +#endif +#ifdef SSL_R_UNSAFE_LEGACY_RENEGOTIATION_DISABLED + || n == SSL_R_UNSAFE_LEGACY_RENEGOTIATION_DISABLED /* 338 */ +#endif +#ifdef SSL_R_SCSV_RECEIVED_WHEN_RENEGOTIATING + || n == SSL_R_SCSV_RECEIVED_WHEN_RENEGOTIATING /* 345 */ +#endif || n == 1000 /* SSL_R_SSLV3_ALERT_CLOSE_NOTIFY */ || n == SSL_R_SSLV3_ALERT_UNEXPECTED_MESSAGE /* 1010 */ || n == SSL_R_SSLV3_ALERT_BAD_RECORD_MAC /* 1020 */ From igor at sysoev.ru Wed Oct 26 08:17:00 2011 From: igor at sysoev.ru (igor at sysoev.ru) Date: Wed, 26 Oct 2011 08:17:00 +0000 Subject: [nginx] svn commit: r4230 - trunk/auto/cc Message-ID: Author: is Date: 2011-10-26 08:16:59 +0000 (Wed, 26 Oct 2011) New Revision: 4230 Modified: trunk/auto/cc/name Log: Fixing building by Microsoft Visual C++ 10 compiler. Modified: trunk/auto/cc/name =================================================================== --- trunk/auto/cc/name 2011-10-25 15:04:09 UTC (rev 4229) +++ trunk/auto/cc/name 2011-10-26 08:16:59 UTC (rev 4230) @@ -25,6 +25,13 @@ if [ "$CC" = cl ]; then if `$NGX_WINE $CC -v 2>&1 \ + | grep '^Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16' \ + >/dev/null 2>&1`; then + + NGX_CC_NAME=msvc10 + echo " + using Microsoft Visual C++ 10 compiler" + + else if `$NGX_WINE $CC -v 2>&1 \ | grep '^Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14' \ >/dev/null 2>&1`; then @@ -43,6 +50,7 @@ echo " + using Microsoft Visual C++ compiler" fi fi + fi else if [ "$CC" = wcl386 ]; then From ru at nginx.com Wed Oct 26 13:18:33 2011 From: ru at nginx.com (ru at nginx.com) Date: Wed, 26 Oct 2011 13:18:33 +0000 Subject: [nginx] svn commit: r4231 - trunk/auto Message-ID: <20111026131833.B9F593F9C1A@mail.nginx.com> Author: ru Date: 2011-10-26 13:18:33 +0000 (Wed, 26 Oct 2011) New Revision: 4231 Log: Revamped "configure --help" text. Modified: trunk/auto/options Modified: trunk/auto/options =================================================================== --- trunk/auto/options 2011-10-26 08:16:59 UTC (rev 4230) +++ trunk/auto/options 2011-10-26 13:18:33 UTC (rev 4231) @@ -306,21 +306,21 @@ cat << END - --help this message + --help print this message - --prefix=PATH set the installation prefix - --sbin-path=PATH set path to the nginx binary file - --conf-path=PATH set path to the nginx.conf file - --error-log-path=PATH set path to the error log - --pid-path=PATH set path to nginx.pid file - --lock-path=PATH set path to nginx.lock file + --prefix=PATH set installation prefix + --sbin-path=PATH set nginx binary pathname + --conf-path=PATH set nginx.conf pathname + --error-log-path=PATH set error log pathname + --pid-path=PATH set nginx.pid pathname + --lock-path=PATH set nginx.lock pathname - --user=USER set non-privilege user - for the worker processes - --group=GROUP set non-privilege group - for the worker processes + --user=USER set non-privileged user for + worker processes + --group=GROUP set non-privileged group for + worker processes - --builddir=DIR set the build directory + --builddir=DIR set build directory --with-rtsig_module enable rtsig module --with-select_module enable select module @@ -328,8 +328,8 @@ --with-poll_module enable poll module --without-poll_module disable poll module - --with-file-aio enable file aio support - --with-ipv6 enable ipv6 support + --with-file-aio enable file AIO support + --with-ipv6 enable IPv6 support --with-http_ssl_module enable ngx_http_ssl_module --with-http_realip_module enable ngx_http_realip_module @@ -372,17 +372,20 @@ disable ngx_http_upstream_ip_hash_module --with-http_perl_module enable ngx_http_perl_module - --with-perl_modules_path=PATH set path to the perl modules - --with-perl=PATH set path to the perl binary + --with-perl_modules_path=PATH set Perl modules path + --with-perl=PATH set perl binary pathname - --http-log-path=PATH set path to the http access log - --http-client-body-temp-path=PATH set path to the http client request body - temporary files - --http-proxy-temp-path=PATH set path to the http proxy temporary files - --http-fastcgi-temp-path=PATH set path to the http fastcgi temporary - files - --http-uwsgi-temp-path=PATH set path to the http uwsgi temporary files - --http-scgi-temp-path=PATH set path to the http scgi temporary files + --http-log-path=PATH set http access log pathname + --http-client-body-temp-path=PATH set path to store + http client request body temporary files + --http-proxy-temp-path=PATH set path to store + http proxy temporary files + --http-fastcgi-temp-path=PATH set path to store + http fastcgi temporary files + --http-uwsgi-temp-path=PATH set path to store + http uwsgi temporary files + --http-scgi-temp-path=PATH set path to store + http scgi temporary files --without-http disable HTTP server --without-http-cache disable HTTP cache @@ -398,40 +401,40 @@ --add-module=PATH enable an external module - --with-cc=PATH set path to C compiler - --with-cpp=PATH set path to C preprocessor - --with-cc-opt=OPTIONS set additional options for C compiler - --with-ld-opt=OPTIONS set additional options for linker - --with-cpu-opt=CPU build for specified CPU, the valid values: + --with-cc=PATH set C compiler pathname + --with-cpp=PATH set C preprocessor pathname + --with-cc-opt=OPTIONS set additional C compiler options + --with-ld-opt=OPTIONS set additional linker options + --with-cpu-opt=CPU build for the specified CPU, valid values: pentium, pentiumpro, pentium3, pentium4, athlon, opteron, sparc32, sparc64, ppc64 --without-pcre disable PCRE library usage --with-pcre force PCRE library usage --with-pcre=DIR set path to PCRE library sources - --with-pcre-opt=OPTIONS set additional options for PCRE building + --with-pcre-opt=OPTIONS set additional build options for PCRE --with-md5=DIR set path to md5 library sources - --with-md5-opt=OPTIONS set additional options for md5 building + --with-md5-opt=OPTIONS set additional build options for md5 --with-md5-asm use md5 assembler sources --with-sha1=DIR set path to sha1 library sources - --with-sha1-opt=OPTIONS set additional options for sha1 building + --with-sha1-opt=OPTIONS set additional build options for sha1 --with-sha1-asm use sha1 assembler sources --with-zlib=DIR set path to zlib library sources - --with-zlib-opt=OPTIONS set additional options for zlib building + --with-zlib-opt=OPTIONS set additional build options for zlib --with-zlib-asm=CPU use zlib assembler sources optimized - for specified CPU, the valid values: + for the specified CPU, valid values: pentium, pentiumpro --with-libatomic force libatomic_ops library usage --with-libatomic=DIR set path to libatomic_ops library sources --with-openssl=DIR set path to OpenSSL library sources - --with-openssl-opt=OPTIONS set additional options for OpenSSL building + --with-openssl-opt=OPTIONS set additional build options for OpenSSL - --with-debug enable the debugging logging + --with-debug enable debug logging END From zzz at zzz.org.ua Wed Oct 26 22:47:50 2011 From: zzz at zzz.org.ua (Alexandr Gomoliako) Date: Thu, 27 Oct 2011 01:47:50 +0300 Subject: embedded perl, patch Message-ID: Hello all. I've been working on embedded perl recently and have some ideas to consider. 1. Allow request-independent asynchronous functions, kind of like this: sub handler { my $r = shift; ngx_get_something "foo", sub { my $something = shift; $r->print($something); ... }; } 2. Remove G_EVAL from callback Mistake in perl handler is as fatal as segfault and nginx should just let it croak. If anyone really wants this, they can always use "eval {}". 3. Ditch multiplicity and clean things up a bit. I can't find any reason to support multiplilicity, especially with asynchronous model. So, in patch there is a simple timer, couple of request related functions and constsubs: sub handler { my $r = shift; $r->main_count_inc; ... ngx_timer 1, 0, sub { $r->print(...); $r->send_special(NGX_HTTP_LAST); $r->finalize_request(NGX_OK); }; ... return NGX_DONE; } Here is a simple example with two timers executing in parallel (second and third) and others sequentually: package hello; use nginx; sub handler { my $r = shift; $r->log_error(0, "handler"); $r->discard_request_body; $r->main_count_inc; ngx_timer 1, 0, sub { $r->log_error(0, "first timer"); ngx_timer 1, 0, sub { $r->log_error(0, "second timer"); }; ngx_timer 1, 0, sub { $r->log_error(0, "third timer"); ngx_timer 1, 0, sub { $r->log_error(0, "last timer, sending response"); $r->send_http_header("text/plain"); $r->print("hello world\n"); $r->send_special(NGX_HTTP_LAST); $r->finalize_request(NGX_OK); }; }; }; return NGX_DONE; } 1; Any thoughts? -------------- next part -------------- A non-text attachment was scrubbed... Name: nginx-perl-pre.patch Type: text/x-patch Size: 9015 bytes Desc: not available URL: From zzz at zzz.org.ua Thu Oct 27 18:51:47 2011 From: zzz at zzz.org.ua (Alexandr Gomoliako) Date: Thu, 27 Oct 2011 21:51:47 +0300 Subject: embedded perl, patch In-Reply-To: References: Message-ID: > Any thoughts? > So, it seems like no one here cares about embedded perl :) That's fine, I'd rather have a fork anyway. From igor at sysoev.ru Thu Oct 27 19:01:32 2011 From: igor at sysoev.ru (Igor Sysoev) Date: Thu, 27 Oct 2011 23:01:32 +0400 Subject: embedded perl, patch In-Reply-To: References: Message-ID: <20111027190132.GA90209@nginx.com> On Thu, Oct 27, 2011 at 01:47:50AM +0300, Alexandr Gomoliako wrote: > 3. Ditch multiplicity and clean things up a bit. > I can't find any reason to support multiplilicity, > especially with asynchronous model. The multiplicity is required to support graceful and fault-tolerant reload: nginx creates new Perl interpreter for a new configuration and frees old interpreter if the new configuration was good. Otherwise, in case of configuration failure you may get a mess of Perl code. -- Igor Sysoev From igor at sysoev.ru Thu Oct 27 19:21:42 2011 From: igor at sysoev.ru (Igor Sysoev) Date: Thu, 27 Oct 2011 23:21:42 +0400 Subject: embedded perl, patch In-Reply-To: References: Message-ID: <20111027192142.GB90209@nginx.com> On Thu, Oct 27, 2011 at 01:47:50AM +0300, Alexandr Gomoliako wrote: > 2. Remove G_EVAL from callback > Mistake in perl handler is as fatal as segfault and > nginx should just let it croak. If anyone really > wants this, they can always use "eval {}". Really ? nginx is not single line pipelined commands. Single mistake should not stop whole server. I believe that nginx should log mistake and allows other requests to proceed. -- Igor Sysoev From zzz at zzz.org.ua Thu Oct 27 19:40:01 2011 From: zzz at zzz.org.ua (Alexandr Gomoliako) Date: Thu, 27 Oct 2011 22:40:01 +0300 Subject: embedded perl, patch In-Reply-To: <20111027190132.GA90209@nginx.com> References: <20111027190132.GA90209@nginx.com> Message-ID: > Really ? nginx is not single line pipelined commands. > Single mistake should not stop whole server. I believe that nginx > should log mistake and allows other requests to proceed. Let's say we are creating a handler and this handler died but was able to create another one. This another handler can cause some damage, do things it isn't supposed to. I understand that it isn't the case currently, but it will be with asynchronous subs. I think it's possible to make perl modules behave more like native modules, even create configuration directives. This will enable anyone to do much more much faster, which is the whole point of embedding perl I believe. From igor at sysoev.ru Fri Oct 28 05:17:34 2011 From: igor at sysoev.ru (Igor Sysoev) Date: Fri, 28 Oct 2011 09:17:34 +0400 Subject: embedded perl, patch In-Reply-To: References: <20111027190132.GA90209@nginx.com> Message-ID: <20111028051734.GA3978@nginx.com> On Thu, Oct 27, 2011 at 10:40:01PM +0300, Alexandr Gomoliako wrote: > > Really ? nginx is not single line pipelined commands. > > Single mistake should not stop whole server. I believe that nginx > > should log mistake and allows other requests to proceed. > > Let's say we are creating a handler and this handler died but > was able to create another one. This another handler can cause > some damage, do things it isn't supposed to. I understand that > it isn't the case currently, but it will be with asynchronous subs. So you usually shutdown host if some single line script fails, because it may cause some damage: files corruption, etc ? > I think it's possible to make perl modules behave more like > native modules, even create configuration directives. > This will enable anyone to do much more much faster, > which is the whole point of embedding perl I believe. Native modules never abort worker process. Never. They try to handle failure gracefully, logging error for developer and showing 500 page for user. -- Igor Sysoev From zzz at zzz.org.ua Fri Oct 28 11:53:58 2011 From: zzz at zzz.org.ua (Alexandr Gomoliako) Date: Fri, 28 Oct 2011 14:53:58 +0300 Subject: embedded perl, patch In-Reply-To: <20111028051734.GA3978@nginx.com> References: <20111027190132.GA90209@nginx.com> <20111028051734.GA3978@nginx.com> Message-ID: On 10/28/11, Igor Sysoev wrote: > On Thu, Oct 27, 2011 at 10:40:01PM +0300, Alexandr Gomoliako wrote: >> > Really ? nginx is not single line pipelined commands. >> > Single mistake should not stop whole server. I believe that nginx >> > should log mistake and allows other requests to proceed. >> >> Let's say we are creating a handler and this handler died but >> was able to create another one. This another handler can cause >> some damage, do things it isn't supposed to. I understand that >> it isn't the case currently, but it will be with asynchronous subs. > > So you usually shutdown host if some single line script fails, > because it may cause some damage: files corruption, etc ? It depends. If it is a load balancer -- of course not. But I don't expect to run anything that can corrupt some data there. However, If application acts as a data storage of some sort, I'd rather shut it down on any error and not take any chances on data corruption, pollution, etc. >> I think it's possible to make perl modules behave more like >> native modules, even create configuration directives. >> This will enable anyone to do much more much faster, >> which is the whole point of embedding perl I believe. > > Native modules never abort worker process. Never. > They try to handle failure gracefully, logging error for developer > and showing 500 page for user. That's right. So perl modules can try to do that too and use eval {} themselves if they need to. From igor at sysoev.ru Fri Oct 28 15:24:32 2011 From: igor at sysoev.ru (igor at sysoev.ru) Date: Fri, 28 Oct 2011 15:24:32 +0000 Subject: [nginx] svn commit: r4232 - trunk/conf Message-ID: Author: is Date: 2011-10-28 15:24:31 +0000 (Fri, 28 Oct 2011) New Revision: 4232 Modified: trunk/conf/mime.types Log: Adding m4a and m4v MIME types (closed #42). Modified: trunk/conf/mime.types =================================================================== --- trunk/conf/mime.types 2011-10-26 13:18:33 UTC (rev 4231) +++ trunk/conf/mime.types 2011-10-28 15:24:31 UTC (rev 4232) @@ -62,6 +62,7 @@ audio/midi mid midi kar; audio/mpeg mp3; audio/ogg ogg; + audio/x-m4a m4a; audio/x-realaudio ra; video/3gpp 3gpp 3gp; @@ -69,6 +70,7 @@ video/mpeg mpeg mpg; video/quicktime mov; video/x-flv flv; + video/x-m4v m4v; video/x-mng mng; video/x-ms-asf asx asf; video/x-ms-wmv wmv; From mdounin at mdounin.ru Mon Oct 31 09:53:17 2011 From: mdounin at mdounin.ru (mdounin at mdounin.ru) Date: Mon, 31 Oct 2011 09:53:17 +0000 Subject: [nginx] svn commit: r4233 - trunk/src/event Message-ID: <20111031095317.916E93F9C1A@mail.nginx.com> Author: mdounin Date: 2011-10-31 09:53:16 +0000 (Mon, 31 Oct 2011) New Revision: 4233 Log: Event pipe: fixes for complex protocols. 1. In ngx_event_pipe_write_chain_to_temp_file() make sure to fully write all shadow buffers up to last_shadow. With this change recycled buffers cannot appear in p->out anymore. This also fixes segmentation faults observed due to ngx_event_pipe_write_chain_to_temp() not freeing any raw buffers while still returning NGX_OK. 2. In ngx_event_pipe_write_to_downstream() we now properly check for busy size as a size of buffers, not a size of data in these buffers. This fixes situations where all available buffers became busy (including segmentation faults due to this). 3. The ngx_event_pipe_free_shadow_raw_buf() function is dropped. It's incorrect and not needed. Modified: trunk/src/event/ngx_event_pipe.c Modified: trunk/src/event/ngx_event_pipe.c =================================================================== --- trunk/src/event/ngx_event_pipe.c 2011-10-28 15:24:31 UTC (rev 4232) +++ trunk/src/event/ngx_event_pipe.c 2011-10-31 09:53:16 UTC (rev 4233) @@ -15,8 +15,6 @@ static ngx_int_t ngx_event_pipe_write_chain_to_temp_file(ngx_event_pipe_t *p); static ngx_inline void ngx_event_pipe_remove_shadow_links(ngx_buf_t *buf); -static ngx_inline void ngx_event_pipe_free_shadow_raw_buf(ngx_chain_t **free, - ngx_buf_t *buf); static ngx_int_t ngx_event_pipe_drain_chains(ngx_event_pipe_t *p); @@ -576,17 +574,13 @@ if (p->out) { cl = p->out; - if (cl->buf->recycled - && bsize + cl->buf->last - cl->buf->pos > p->busy_size) - { - flush = 1; - break; + if (cl->buf->recycled) { + ngx_log_error(NGX_LOG_ALERT, p->log, 0, + "recycled buffer in pipe out chain"); } p->out = p->out->next; - ngx_event_pipe_free_shadow_raw_buf(&p->free_raw_bufs, cl->buf); - } else if (!p->cacheable && p->in) { cl = p->in; @@ -596,24 +590,13 @@ cl->buf->pos, cl->buf->last - cl->buf->pos); - if (cl->buf->recycled - && cl->buf->last_shadow - && bsize + cl->buf->last - cl->buf->pos > p->busy_size) - { - if (!prev_last_shadow) { - p->in = p->in->next; - - cl->next = NULL; - - if (out) { - *ll = cl; - } else { - out = cl; - } + if (cl->buf->recycled && prev_last_shadow) { + if (bsize + cl->buf->end - cl->buf->start > p->busy_size) { + flush = 1; + break; } - flush = 1; - break; + bsize += cl->buf->end - cl->buf->start; } prev_last_shadow = cl->buf->last_shadow; @@ -624,10 +607,6 @@ break; } - if (cl->buf->recycled) { - bsize += cl->buf->last - cl->buf->pos; - } - cl->next = NULL; if (out) { @@ -703,6 +682,7 @@ { ssize_t size, bsize; ngx_buf_t *b; + ngx_uint_t prev_last_shadow; ngx_chain_t *cl, *tl, *next, *out, **ll, **last_free, fl; if (p->buf_to_file) { @@ -719,6 +699,7 @@ size = 0; cl = out; ll = NULL; + prev_last_shadow = 1; ngx_log_debug1(NGX_LOG_DEBUG_EVENT, p->log, 0, "pipe offset: %O", p->temp_file->offset); @@ -726,16 +707,21 @@ do { bsize = cl->buf->last - cl->buf->pos; - ngx_log_debug3(NGX_LOG_DEBUG_EVENT, p->log, 0, - "pipe buf %p, pos %p, size: %z", - cl->buf->start, cl->buf->pos, bsize); + ngx_log_debug4(NGX_LOG_DEBUG_EVENT, p->log, 0, + "pipe buf ls:%d %p, pos %p, size: %z", + cl->buf->last_shadow, cl->buf->start, + cl->buf->pos, bsize); - if ((size + bsize > p->temp_file_write_size) - || (p->temp_file->offset + size + bsize > p->max_temp_file_size)) + if (prev_last_shadow + && ((size + bsize > p->temp_file_write_size) + || (p->temp_file->offset + size + bsize + > p->max_temp_file_size))) { break; } + prev_last_shadow = cl->buf->last_shadow; + size += bsize; ll = &cl->next; cl = cl->next; @@ -913,35 +899,6 @@ } -static ngx_inline void -ngx_event_pipe_free_shadow_raw_buf(ngx_chain_t **free, ngx_buf_t *buf) -{ - ngx_buf_t *s; - ngx_chain_t *cl, **ll; - - if (buf->shadow == NULL) { - return; - } - - for (s = buf->shadow; !s->last_shadow; s = s->shadow) { /* void */ } - - ll = free; - - for (cl = *free; cl; cl = cl->next) { - if (cl->buf == s) { - *ll = cl->next; - break; - } - - if (cl->buf->shadow) { - break; - } - - ll = &cl->next; - } -} - - ngx_int_t ngx_event_pipe_add_free_buf(ngx_event_pipe_t *p, ngx_buf_t *b) { From mdounin at mdounin.ru Mon Oct 31 09:54:55 2011 From: mdounin at mdounin.ru (mdounin at mdounin.ru) Date: Mon, 31 Oct 2011 09:54:55 +0000 Subject: [nginx] svn commit: r4234 - trunk/src/event Message-ID: <20111031095456.98C3A3F9C2F@mail.nginx.com> Author: mdounin Date: 2011-10-31 09:54:55 +0000 (Mon, 31 Oct 2011) New Revision: 4234 Log: Event pipe: reduced number of file buffers used. If possible we now just extend already present file buffer in p->out chain instead of keeping ngx_buf_t for each buffer we've flushed to disk. This saves about 120 bytes of memory per buffer flushed to disk, and resolves high CPU usage observed in edge cases (due to coalescing these buffers on send). Modified: trunk/src/event/ngx_event_pipe.c trunk/src/event/ngx_event_pipe.h Modified: trunk/src/event/ngx_event_pipe.c =================================================================== --- trunk/src/event/ngx_event_pipe.c 2011-10-31 09:53:16 UTC (rev 4233) +++ trunk/src/event/ngx_event_pipe.c 2011-10-31 09:54:55 UTC (rev 4234) @@ -680,10 +680,10 @@ static ngx_int_t ngx_event_pipe_write_chain_to_temp_file(ngx_event_pipe_t *p) { - ssize_t size, bsize; + ssize_t size, bsize, n; ngx_buf_t *b; ngx_uint_t prev_last_shadow; - ngx_chain_t *cl, *tl, *next, *out, **ll, **last_free, fl; + ngx_chain_t *cl, *tl, *next, *out, **ll, **last_out, **last_free, fl; if (p->buf_to_file) { fl.buf = p->buf_to_file; @@ -748,43 +748,78 @@ p->last_in = &p->in; } - if (ngx_write_chain_to_temp_file(p->temp_file, out) == NGX_ERROR) { + n = ngx_write_chain_to_temp_file(p->temp_file, out); + + if (n == NGX_ERROR) { return NGX_ABORT; } - for (last_free = &p->free_raw_bufs; - *last_free != NULL; - last_free = &(*last_free)->next) - { - /* void */ - } - if (p->buf_to_file) { p->temp_file->offset = p->buf_to_file->last - p->buf_to_file->pos; + n -= p->buf_to_file->last - p->buf_to_file->pos; p->buf_to_file = NULL; out = out->next; } - for (cl = out; cl; cl = next) { - next = cl->next; - cl->next = NULL; + if (n > 0) { + /* update previous buffer or add new buffer */ + if (p->out) { + for (cl = p->out; cl->next; cl = cl->next) { /* void */ } + + b = cl->buf; + + if (b->file_last == p->temp_file->offset) { + p->temp_file->offset += n; + b->file_last = p->temp_file->offset; + goto free; + } + + last_out = &cl->next; + + } else { + last_out = &p->out; + } + + cl = ngx_chain_get_free_buf(p->pool, &p->free); + if (cl == NULL) { + return NGX_ABORT; + } + b = cl->buf; + + ngx_memzero(b, sizeof(ngx_buf_t)); + + b->tag = p->tag; + b->file = &p->temp_file->file; b->file_pos = p->temp_file->offset; - p->temp_file->offset += b->last - b->pos; + p->temp_file->offset += n; b->file_last = p->temp_file->offset; b->in_file = 1; b->temp_file = 1; - if (p->out) { - *p->last_out = cl; - } else { - p->out = cl; - } - p->last_out = &cl->next; + *last_out = cl; + } +free: + + for (last_free = &p->free_raw_bufs; + *last_free != NULL; + last_free = &(*last_free)->next) + { + /* void */ + } + + for (cl = out; cl; cl = next) { + next = cl->next; + + cl->next = p->free; + p->free = cl; + + b = cl->buf; + if (b->last_shadow) { tl = ngx_alloc_chain_link(p->pool); Modified: trunk/src/event/ngx_event_pipe.h =================================================================== --- trunk/src/event/ngx_event_pipe.h 2011-10-31 09:53:16 UTC (rev 4233) +++ trunk/src/event/ngx_event_pipe.h 2011-10-31 09:54:55 UTC (rev 4234) @@ -30,8 +30,6 @@ ngx_chain_t **last_in; ngx_chain_t *out; - ngx_chain_t **last_out; - ngx_chain_t *free; ngx_chain_t *busy; From mdounin at mdounin.ru Mon Oct 31 09:57:14 2011 From: mdounin at mdounin.ru (mdounin at mdounin.ru) Date: Mon, 31 Oct 2011 09:57:14 +0000 Subject: [nginx] svn commit: r4235 - trunk/src/http/modules Message-ID: <20111031095714.80A813F9C1A@mail.nginx.com> Author: mdounin Date: 2011-10-31 09:57:14 +0000 (Mon, 31 Oct 2011) New Revision: 4235 Log: Fixed segfault on configuration testing with ssl (ticket #37). The following config caused segmentation fault due to conf->file not being properly set if "ssl on" was inherited from the http level: http { ssl on; server { } } Modified: trunk/src/http/modules/ngx_http_ssl_module.c Modified: trunk/src/http/modules/ngx_http_ssl_module.c =================================================================== --- trunk/src/http/modules/ngx_http_ssl_module.c 2011-10-31 09:54:55 UTC (rev 4234) +++ trunk/src/http/modules/ngx_http_ssl_module.c 2011-10-31 09:57:14 UTC (rev 4235) @@ -346,8 +346,17 @@ ngx_pool_cleanup_t *cln; - ngx_conf_merge_value(conf->enable, prev->enable, 0); + if (conf->enable == NGX_CONF_UNSET) { + if (prev->enable == NGX_CONF_UNSET) { + conf->enable = 0; + } else { + conf->enable = prev->enable; + conf->file = prev->file; + conf->line = prev->line; + } + } + ngx_conf_merge_value(conf->session_timeout, prev->session_timeout, 300); From ru at nginx.com Mon Oct 31 10:38:21 2011 From: ru at nginx.com (ru at nginx.com) Date: Mon, 31 Oct 2011 10:38:21 +0000 Subject: [nginx] svn commit: r4236 - trunk/docs/text Message-ID: <20111031103821.3ED783F9C1B@mail.nginx.com> Author: ru Date: 2011-10-31 10:38:20 +0000 (Mon, 31 Oct 2011) New Revision: 4236 Log: Fixed documentation pointer. Modified: trunk/docs/text/README Modified: trunk/docs/text/README =================================================================== --- trunk/docs/text/README 2011-10-31 09:57:14 UTC (rev 4235) +++ trunk/docs/text/README 2011-10-31 10:38:20 UTC (rev 4236) @@ -1,4 +1,3 @@ -The Russian documentation is available at http://sysoev.ru/nginx/ -The English documentation is available at http://nginx.net +Documentation is available at http://nginx.org From igor at sysoev.ru Mon Oct 31 14:30:04 2011 From: igor at sysoev.ru (igor at sysoev.ru) Date: Mon, 31 Oct 2011 14:30:04 +0000 Subject: [nginx] svn commit: r4237 - trunk/src/event Message-ID: Author: is Date: 2011-10-31 14:30:03 +0000 (Mon, 31 Oct 2011) New Revision: 4237 Modified: trunk/src/event/ngx_event_openssl.c Log: Silently ignoring a stale global SSL error left after disabled renegotiation. Modified: trunk/src/event/ngx_event_openssl.c =================================================================== --- trunk/src/event/ngx_event_openssl.c 2011-10-31 10:38:20 UTC (rev 4236) +++ trunk/src/event/ngx_event_openssl.c 2011-10-31 14:30:03 UTC (rev 4237) @@ -863,6 +863,13 @@ ngx_log_error(NGX_LOG_NOTICE, c->log, 0, "SSL renegotiation disabled"); + while (ERR_peek_error()) { + ngx_ssl_error(NGX_LOG_DEBUG, c->log, 0, + "ignoring stale global SSL error"); + } + + ERR_clear_error(); + c->ssl->no_wait_shutdown = 1; c->ssl->no_send_shutdown = 1; From igor at sysoev.ru Mon Oct 31 14:52:47 2011 From: igor at sysoev.ru (igor at sysoev.ru) Date: Mon, 31 Oct 2011 14:52:47 +0000 Subject: [nginx] svn commit: r4238 - trunk/docs/xml/nginx Message-ID: Author: is Date: 2011-10-31 14:52:46 +0000 (Mon, 31 Oct 2011) New Revision: 4238 Modified: trunk/docs/xml/nginx/changes.xml Log: nginx-1.1.7-RELEASE Modified: trunk/docs/xml/nginx/changes.xml =================================================================== --- trunk/docs/xml/nginx/changes.xml 2011-10-31 14:30:03 UTC (rev 4237) +++ trunk/docs/xml/nginx/changes.xml 2011-10-31 14:52:46 UTC (rev 4238) @@ -9,6 +9,66 @@ nginx changelog + + + + +????????? ?????????? DNS ???????? ? ????????? "resolver".
+??????? ??????? ??????????. + + +support of several resolvers in the "resolver" directive.
+Thanks to Kirill A. Korinskiy. + + + + + +?? ?????? ??? ?? ????? ???????????????? ?????????? segmentation fault, +???? ????????? ssl ?????????????? ?? ?????? http ? ?? ??? ?????? +ssl_certificate. + + +a segmentation fault occurred on start or while reconfiguration +if the "ssl" directive was used at http level and there was +no "ssl_certificate" defined. + + + + + +????????? ??????????? ?????? ??? ????????????? ??????? ??????, +???? ??? ???????????????? ?? ????. + + +reduced memory consumption while proxying of big files +if they were buffered to disk. + + + + + +? ??????? ???????? ??? ????????? segmentation fault, +???? ?????????????? ????????? "proxy_http_version 1.1". + + +a segmentation fault might occur in a worker process +if "proxy_http_version 1.1" directive was used. + + + + + +? ????????? "expires @time". + + +in the "expires @time" directive. + + + + + + From igor at sysoev.ru Mon Oct 31 14:52:54 2011 From: igor at sysoev.ru (igor at sysoev.ru) Date: Mon, 31 Oct 2011 14:52:54 +0000 Subject: [nginx] svn commit: r4239 - tags Message-ID: Author: is Date: 2011-10-31 14:52:53 +0000 (Mon, 31 Oct 2011) New Revision: 4239 Added: tags/release-1.1.7/ Log: release-1.1.7 tag