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
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
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 |
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.
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
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
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
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
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
>>>
>>
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
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
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
>
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:
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
14 matches
Mail list logo