[nginx] Stream: removed useless typedef.

details: http://hg.nginx.org/nginx/rev/4eb1b5c6d9c6 branches: changeset: 6392:4eb1b5c6d9c6 user: Roman Arutyunyan date: Thu Feb 11 14:20:22 2016 +0300 description: Stream: removed useless typedef. diffstat: src/stream/ngx_stream_proxy_module.c | 3 --- 1 files changed, 0 insertio

[nginx] Stream: initialize variable right before using it.

details: http://hg.nginx.org/nginx/rev/70e6e1f12dee branches: changeset: 6393:70e6e1f12dee user: Roman Arutyunyan date: Thu Feb 11 14:20:26 2016 +0300 description: Stream: initialize variable right before using it. diffstat: src/stream/ngx_stream_proxy_module.c | 4 ++-- 1 files

[nginx] Dynamic modules: fixed a version mismatch message (ticke...

details: http://hg.nginx.org/nginx/rev/5fe617f38222 branches: changeset: 6394:5fe617f38222 user: Ruslan Ermilov date: Thu Feb 11 18:46:46 2016 +0300 description: Dynamic modules: fixed a version mismatch message (ticket #898). Based on a patch by Takashi Takizawa. diffstat: src/c

[nginx] HTTP/2: implemented HPACK Huffman encoding for response ...

details: http://hg.nginx.org/nginx/rev/ba3c2ca21aa5 branches: changeset: 6395:ba3c2ca21aa5 user: Valentin Bartenev date: Thu Feb 11 15:35:36 2016 +0300 description: HTTP/2: implemented HPACK Huffman encoding for response headers. This reduces the size of headers by over 30% on avera

Re: [PATCH] HTTP/2: HPACK Huffman encoding

On Friday 22 January 2016 13:53:01 Valentin V. Bartenev wrote: > On Wednesday 20 January 2016 14:01:15 Vlad Krasnov wrote: > > LGTM > > > > Cheers, > > Vlad > > > [..] > > Thank you. The patch will be committed after internal review. > [..] Committed with the changes made during the review: h

Re: [PATCH] HTTP/2: HPACK Huffman encoding

I am very happy! Thank you Valentin. Cheers, Vlad > On 11 Feb 2016, at 08:36, Valentin V. Bartenev wrote: > > On Friday 22 January 2016 13:53:01 Valentin V. Bartenev wrote: >> On Wednesday 20 January 2016 14:01:15 Vlad Krasnov wrote: >>> LGTM >>> >>> Cheers, >>> Vlad >>> >> [..] >> >> Thank

Dynamic module search paths?

Hi folks It seems to me that the the load_module directive for loading NGINX dynamic modules just use the server prefix when resolving relative module DSO file paths specified in nginx.conf. Here is my wishlist: I hope that we can have support for module search paths specified via an external env

Already loaded NGINX modules

Hi guys! Currently when an NGINX module is statically linked against the NGINX binary, the load_module directive bails out the server startup with the error message "module already loaded" (or something like that). Hopefully we can make this a nonfatal error (or provide an option to make it nonfat

Add /etc/hosts support to NGINX's own resolver

Hi guys! I wonder if you have any plans or interest in adding support for system hosts configuration files (like /etc/hosts on Linux/*BSD/Mac OS X) to NGINX's own nonblocking resolver implementation. This makes debugging and other sysadmin work much easier otherwise we must set up a local DNS serv

Re: Already loaded NGINX modules

Hey Yichun, > Currently when an NGINX module is statically linked against the NGINX > binary, the load_module directive bails out the server startup with > the error message "module already loaded" (or something like that). > Hopefully we can make this a nonfatal error (or provide an option to > m

Re: Already loaded NGINX modules

Hello! On Thu, Feb 11, 2016 at 2:33 PM, Piotr Sikora wrote: > I disagree, because this would lead to unexpected behavior (since > statically linked module can be slightly different from the dynamic > module). > > Which version should be used at runtime in your non-fatal scenario and why? We don't

Re: Already loaded NGINX modules

Hello! On Thu, Feb 11, 2016 at 3:16 PM, Yichun Zhang (agentzh) wrote: > We don't have version numbers in the DSO file names anyway :) And we > can issue warnings to error.log, even with a high log level. > Or with an explicit option to the load_module directive, as in load_module ngx_http_lu

Re: Already loaded NGINX modules

Hey Yichun, > Or with an explicit option to the load_module directive, as in > > load_module ngx_http_lua_module.so duplicate=ignore; > > What about this? That doesn't really answer my question: which version (statically linked or dynamic) of the module should we use at runtime if both are pr

Re: Already loaded NGINX modules

Hello! On Thu, Feb 11, 2016 at 3:29 PM, Piotr Sikora wrote: > > That doesn't really answer my question: which version (statically > linked or dynamic) of the module should we use at runtime if both are > present... and why? > For portable NGINX-based applications, for example, we only want to ens