Re: Looking for developer to fix a NginX test case module

On Mon, Aug 5, 2013 at 1:28 AM, Maxim Konovalov wrote: > On 8/2/13 8:44 PM, Julien Zefi wrote: > > On Wed, Jul 31, 2013 at 3:33 PM, Julien Zefi > > wrote: > > > > > > On Tue, Jul 30, 2013 at 3:34 AM, Maxim Dounin > > mailto:mdou...@mdounin.ru>> wrote: > > > >

[PATCH] SSL: support automatic selection of ECDH temporary key parameters

# HG changeset patch # User Piotr Sikora # Date 1375735677 25200 # Mon Aug 05 13:47:57 2013 -0700 # Node ID bff5a43ea1596c1b0d2bb0b2fe698c7c79d8348a # Parent 997b00c5c7f377a6c18874311fe39f22655616f6 SSL: support automatic selection of ECDH temporary key parameters. Signed-off-by: Piotr Siko

[PATCH] SSL: support ALPN (IETF's successor to NPN)

# HG changeset patch # User Piotr Sikora # Date 1375735383 25200 # Mon Aug 05 13:43:03 2013 -0700 # Node ID 997b00c5c7f377a6c18874311fe39f22655616f6 # Parent 31932b5464f0230d5039fafed94c33f495da35f6 SSL: support ALPN (IETF's successor to NPN). Signed-off-by: Piotr Sikora diff -r 31932b546

Re: cache for ngx_http_time()

Actually this is "Last-Modified:" header. In case of several files, caching will improve processing speed, but it is useful for benchmarks only. In real life environment we have tons of files. ___ nginx-devel mailing list nginx-devel@nginx.org http://ma

cache for ngx_http_time()

Hi! ngx_http_time() is called once per request and it call a heavy ngx_sprintf() function. Why not cache the output for one second (resolution of time_t)? I find nice time caching framework on ngx_times.c, with slots and memory barriers, but ngx_http_time() is not using it for some reason. In this

[nginx] Image filter: use "application/json" MIME type for JSON ...

details: http://hg.nginx.org/nginx/rev/31932b5464f0 branches: changeset: 5315:31932b5464f0 user: Valentin Bartenev date: Mon Aug 05 14:30:03 2013 +0400 description: Image filter: use "application/json" MIME type for JSON output. As it is defined by RFC 4627, and allows for various b

[nginx] Core: guard use of AI_ADDRCONFIG.

details: http://hg.nginx.org/nginx/rev/0300d97c6084 branches: changeset: 5314:0300d97c6084 user: Ruslan Ermilov date: Mon Aug 05 13:44:56 2013 +0400 description: Core: guard use of AI_ADDRCONFIG. Some systems (notably NetBSD and OpenBSD) lack AI_ADDRCONFIG support. Reported by Piot

Re: [PATCH] Core: guard use of AI_ADDRCONFIG

Hey Ruslan, > Thanks. I suggest a different patch instead: > (...) > diff --git a/auto/unix b/auto/unix > --- a/auto/unix > +++ b/auto/unix > @@ -788,11 +788,7 @@ ngx_feature_incs="#include >#include " > ngx_feature_path= > ngx_feature_libs= > -ngx_feature_test='struct addr

Re: [PATCH] Core: guard use of AI_ADDRCONFIG

On Mon, Aug 05, 2013 at 12:45:11AM -0700, Piotr Sikora wrote: > # HG changeset patch > # User Piotr Sikora > # Date 1375688648 0 > # Mon Aug 05 07:44:08 2013 + > # Node ID c9e0a2f54810335ba91b86fdb92ef63571680dae > # Parent ec8594b9bf11de3599af15de8e73e41bf7a8b42c > Core: guard use of AI

Re: Dead code in accept

I agree, I view dead code at run-time as a liability. Something that can go wrong. At compile time, you know everything about the sytem, the config script makes assumptions and the binaries shouldnt work if moved to a different OS etc anyway. I am not a nginx developer just a C++ developer. On M

[PATCH] Core: guard use of AI_ADDRCONFIG

# HG changeset patch # User Piotr Sikora # Date 1375688648 0 # Mon Aug 05 07:44:08 2013 + # Node ID c9e0a2f54810335ba91b86fdb92ef63571680dae # Parent ec8594b9bf11de3599af15de8e73e41bf7a8b42c Core: guard use of AI_ADDRCONFIG. AI_ADDRCONFIG is not available on all operating systems (e.g.

[nginx] Fixed build with signed socklen_t and unix sockets.

details: http://hg.nginx.org/nginx/rev/1fe5f7fb6ced branches: changeset: 5313:1fe5f7fb6ced user: Maxim Dounin date: Mon Aug 05 11:40:33 2013 +0400 description: Fixed build with signed socklen_t and unix sockets. This seems to be the case at least under Cygwin, where build was broken

Re: Looking for developer to fix a NginX test case module

On 8/2/13 8:44 PM, Julien Zefi wrote: > On Wed, Jul 31, 2013 at 3:33 PM, Julien Zefi > wrote: > > > On Tue, Jul 30, 2013 at 3:34 AM, Maxim Dounin > mailto:mdou...@mdounin.ru>> wrote: > > Hello! > > On Mon, Jul 29, 2013 at 07:07:10PM -0600, Julie

Re: Dead code in accept

1. Amount of instructions is somewhat bigger - about 500 bytes. 2. In high load you have thousands of accept()s per second. 3. No, I do not talk about adding some code, conversely - actually I want remove dead code! :) > Frankly, I don't see the need. We're talking about eliminating 4 or 5 CPU > i

Re: Dead code in accept

Frankly, I don't see the need. We're talking about eliminating 4 or 5 CPU instructions per accept() call which only seems relevant if that's the only thing nginx does: but with HTTP pipelining this optimization is very insignificant as that already reduces the amount of accept() calls a lot. Als