Re: Restrictions to modifying request->headers_in.headers in NGX_HTTP_PREACCESS_PHASE?

2018-03-29 Thread Robert Paprocki 
Hello,

On Thu, Mar 29, 2018 at 11:06 AM, Ryan Burn  wrote:
>
>
> This module injects multiple headers and the number, keys, etc aren't
> meant to be exposed to the user.
>
> (This module is mean to support tracing and the injected headers btw
> correspond to a SpanContext:
> http://opentracing.io/documentation/pages/api/cross-process-tracing.html
> which varies by the trace used).
>
> Is there way to accomplish this without having the configuration
> author do anything?
>


What's the source of these header names/values? If it's passed from the
downstream client, it will automatically be proxied to the upstream server
(with some exceptions, see the proxy module documentation).

If it's generated on the Nginx node itself, you should be able to use the
proxy_set_header Maxim defined above, in combination with variables which
could be generated via your custom module or some other approach.
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: Restrictions to modifying request->headers_in.headers in NGX_HTTP_PREACCESS_PHASE?

2018-03-29 Thread Ryan Burn 
On Thu, Mar 29, 2018 at 9:40 AM, Maxim Dounin  wrote:
> Hello!
>
> On Wed, Mar 28, 2018 at 04:15:44PM -0400, Ryan Burn wrote:
>
>> > You are not allowed to modify r->headers_in, at any time.
>>
>> If I want to ensure that certain headers are added if the request is
>> proxied upstream, is there any way to do that?
>
> Recommended approach is to export a variable with the appropriate
> value, and use
>
> proxy_set_header X-Your-Header $your_variable;

This module injects multiple headers and the number, keys, etc aren't
meant to be exposed to the user.

(This module is mean to support tracing and the injected headers btw
correspond to a SpanContext:
http://opentracing.io/documentation/pages/api/cross-process-tracing.html
which varies by the trace used).

Is there way to accomplish this without having the configuration
author do anything?
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: Access Nginx variables from HTTP modules

2018-03-29 Thread Paulo Silva 
Would it be Ok doing something like?

ngx_str_t variable_name   = ngx_string("request_id");
ngx_uint_t variable_name_hash;
ngx_http_variable_value_t *variable  = NULL;

variable_name_hash = ngx_hash_key(variable_name.data, variable_name.len);

variable = ngx_http_get_variable(r, _name, variable_name_hash);

On Thu, Mar 29, 2018 at 4:39 PM, Vladimir Homutov  wrote:
> On Thu, Mar 29, 2018 at 04:17:02PM +0100, Paulo Silva wrote:
>> Hi everyone,
>> can you point me the right way to access Nginx variables from my HTTP module?
>>
>> I am looking for a way to read the $request_id value from within one
>> of my modules' functions.
>>
>
> http://nginx.org/en/docs/dev/development_guide.html#http_variables
>
> ___
> nginx-devel mailing list
> nginx-devel@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel



-- 
Paulo A. Silva
https://a-caminho.de
https://tech.pauloasilva.com
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: Access Nginx variables from HTTP modules

2018-03-29 Thread Vladimir Homutov 
On Thu, Mar 29, 2018 at 04:17:02PM +0100, Paulo Silva wrote:
> Hi everyone,
> can you point me the right way to access Nginx variables from my HTTP module?
>
> I am looking for a way to read the $request_id value from within one
> of my modules' functions.
>

http://nginx.org/en/docs/dev/development_guide.html#http_variables

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Access Nginx variables from HTTP modules

2018-03-29 Thread Paulo Silva 
Hi everyone,
can you point me the right way to access Nginx variables from my HTTP module?

I am looking for a way to read the $request_id value from within one
of my modules' functions.

Thanks,
Paulo A. Silva
https://a-caminho.de
https://tech.pauloasilva.com
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: ngx_write_fd

2018-03-29 Thread Ruslan Ermilov 
On Thu, Mar 29, 2018 at 08:51:08AM +, Antonio Nappa wrote:
> Hi,
> 
> I was wondering what happens with ngx_write_fd function and multiple
> workers, I have made some tests and it doesn't look like they are
> interfering with each other and writing in the middle of a line. However I
> am not sure, that's the reason of my question. The file was opened with the
> ngx_conf_open_file.

This is guaranteed by opening the files with O_APPEND; see
ngx_init_cycle() and NGX_FILE_APPEND.
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: Restrictions to modifying request->headers_in.headers in NGX_HTTP_PREACCESS_PHASE?

2018-03-29 Thread Maxim Dounin 
Hello!

On Wed, Mar 28, 2018 at 04:15:44PM -0400, Ryan Burn wrote:

> > You are not allowed to modify r->headers_in, at any time.
> 
> If I want to ensure that certain headers are added if the request is
> proxied upstream, is there any way to do that?

Recommended approach is to export a variable with the appropriate 
value, and use

proxy_set_header X-Your-Header $your_variable;

in the configuration.

For example, nginx itself uses this approach with X-Forwarded-For, 
see the $proxy_add_x_forwarded_for variable description here:

http://nginx.org/en/docs/http/ngx_http_proxy_module.html#var_proxy_add_x_forwarded_for

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

[njs] Added additional log routines for different nginx log levels.

2018-03-29 Thread Dmitry Volyntsev 
details:   http://hg.nginx.org/njs/rev/36ef67f13052
branches:  
changeset: 472:36ef67f13052
user:  Dmitry Volyntsev 
date:  Thu Mar 29 16:38:02 2018 +0300
description:
Added additional log routines for different nginx log levels.

warn(), error().

diffstat:

 nginx/ngx_http_js_module.c   |  82 +--
 nginx/ngx_stream_js_module.c |  67 +--
 2 files changed, 131 insertions(+), 18 deletions(-)

diffs (235 lines):

diff -r ecf693afd698 -r 36ef67f13052 nginx/ngx_http_js_module.c
--- a/nginx/ngx_http_js_module.cTue Mar 27 19:11:04 2018 +0300
+++ b/nginx/ngx_http_js_module.cThu Mar 29 16:38:02 2018 +0300
@@ -89,8 +89,16 @@ static njs_ret_t ngx_http_js_ext_send(nj
 nxt_uint_t nargs, njs_index_t unused);
 static njs_ret_t ngx_http_js_ext_finish(njs_vm_t *vm, njs_value_t *args,
 nxt_uint_t nargs, njs_index_t unused);
+
 static njs_ret_t ngx_http_js_ext_log(njs_vm_t *vm, njs_value_t *args,
 nxt_uint_t nargs, njs_index_t unused);
+static njs_ret_t ngx_http_js_ext_warn(njs_vm_t *vm, njs_value_t *args,
+nxt_uint_t nargs, njs_index_t unused);
+static njs_ret_t ngx_http_js_ext_error(njs_vm_t *vm, njs_value_t *args,
+nxt_uint_t nargs, njs_index_t unused);
+static njs_ret_t ngx_http_js_ext_log_core(njs_vm_t *vm, njs_value_t *args,
+nxt_uint_t nargs, ngx_uint_t level);
+
 static njs_ret_t ngx_http_js_ext_get_http_version(njs_vm_t *vm,
 njs_value_t *value, void *obj, uintptr_t data);
 static njs_ret_t ngx_http_js_ext_get_remote_address(njs_vm_t *vm,
@@ -287,18 +295,6 @@ static njs_external_t  ngx_http_js_ext_r
 
 static njs_external_t  ngx_http_js_ext_request[] = {
 
-{ nxt_string("log"),
-  NJS_EXTERN_METHOD,
-  NULL,
-  0,
-  NULL,
-  NULL,
-  NULL,
-  NULL,
-  NULL,
-  ngx_http_js_ext_log,
-  0 },
-
 { nxt_string("uri"),
   NJS_EXTERN_PROPERTY,
   NULL,
@@ -406,6 +402,42 @@ static njs_external_t  ngx_http_js_ext_r
   NULL,
   ngx_http_js_ext_subrequest,
   0 },
+
+{ nxt_string("log"),
+  NJS_EXTERN_METHOD,
+  NULL,
+  0,
+  NULL,
+  NULL,
+  NULL,
+  NULL,
+  NULL,
+  ngx_http_js_ext_log,
+  0 },
+
+{ nxt_string("warn"),
+  NJS_EXTERN_METHOD,
+  NULL,
+  0,
+  NULL,
+  NULL,
+  NULL,
+  NULL,
+  NULL,
+  ngx_http_js_ext_warn,
+  0 },
+
+{ nxt_string("error"),
+  NJS_EXTERN_METHOD,
+  NULL,
+  0,
+  NULL,
+  NULL,
+  NULL,
+  NULL,
+  NULL,
+  ngx_http_js_ext_error,
+  0 },
 };
 
 
@@ -1226,6 +1258,30 @@ static njs_ret_t
 ngx_http_js_ext_log(njs_vm_t *vm, njs_value_t *args, nxt_uint_t nargs,
 njs_index_t unused)
 {
+return ngx_http_js_ext_log_core(vm, args, nargs, NGX_LOG_INFO);
+}
+
+
+static njs_ret_t
+ngx_http_js_ext_warn(njs_vm_t *vm, njs_value_t *args, nxt_uint_t nargs,
+njs_index_t unused)
+{
+return ngx_http_js_ext_log_core(vm, args, nargs, NGX_LOG_WARN);
+}
+
+
+static njs_ret_t
+ngx_http_js_ext_error(njs_vm_t *vm, njs_value_t *args, nxt_uint_t nargs,
+njs_index_t unused)
+{
+return ngx_http_js_ext_log_core(vm, args, nargs, NGX_LOG_ERR);
+}
+
+
+static njs_ret_t
+ngx_http_js_ext_log_core(njs_vm_t *vm, njs_value_t *args, nxt_uint_t nargs,
+ngx_uint_t level)
+{
 nxt_str_tmsg;
 ngx_connection_t*c;
 ngx_log_handler_pt   handler;
@@ -1243,7 +1299,7 @@ ngx_http_js_ext_log(njs_vm_t *vm, njs_va
 handler = c->log->handler;
 c->log->handler = NULL;
 
-ngx_log_error(NGX_LOG_INFO, c->log, 0, "js: %*s", msg.length, msg.start);
+ngx_log_error(level, c->log, 0, "js: %*s", msg.length, msg.start);
 
 c->log->handler = handler;
 
diff -r ecf693afd698 -r 36ef67f13052 nginx/ngx_stream_js_module.c
--- a/nginx/ngx_stream_js_module.c  Tue Mar 27 19:11:04 2018 +0300
+++ b/nginx/ngx_stream_js_module.c  Thu Mar 29 16:38:02 2018 +0300
@@ -63,8 +63,16 @@ static njs_ret_t ngx_stream_js_ext_get_b
 void *obj, uintptr_t data);
 static njs_ret_t ngx_stream_js_ext_set_buffer(njs_vm_t *vm, void *obj,
 uintptr_t data, nxt_str_t *value);
- static njs_ret_t ngx_stream_js_ext_log(njs_vm_t *vm, njs_value_t *args,
+
+static njs_ret_t ngx_stream_js_ext_log(njs_vm_t *vm, njs_value_t *args,
+ nxt_uint_t nargs, njs_index_t unused);
+static njs_ret_t ngx_stream_js_ext_warn(njs_vm_t *vm, njs_value_t *args,
  nxt_uint_t nargs, njs_index_t unused);
+static njs_ret_t ngx_stream_js_ext_error(njs_vm_t *vm, njs_value_t *args,
+ nxt_uint_t nargs, njs_index_t unused);
+static njs_ret_t ngx_stream_js_ext_log_core(njs_vm_t *vm, njs_value_t *args,
+nxt_uint_t nargs, ngx_uint_t level);
+
 static njs_ret_t ngx_stream_js_ext_get_variable(njs_vm_t *vm,
 njs_value_t *value, void *obj, uintptr_t data);
 static njs_ret_t ngx_stream_js_ext_get_code(njs_vm_t *vm,
@@ -199,6 +207,19 @@ static njs_external_t  ngx_stream_js_ext
   NULL,

Re: ngx_write_fd

2018-03-29 Thread Vasily Soshnikov 
Hi,

The UNIX-like system does not guarantee atomic write to a file (i.e.
regular file). Actual, it works sometimes and for some system with tons of
limitation. I prefer to avoid this practice.

What can you do? You can lock (i.e. flock() and so on) file for writing,
It's synchronization of concurrent access.

Also, I suggest reading about fsync(), fdatasync() and kernel cache, if you
wish to avoid the power-off problem.




On 29 March 2018 at 11:51, Antonio Nappa  wrote:

> Hi,
>
> I was wondering what happens with ngx_write_fd function and multiple
> workers, I have made some tests and it doesn't look like they are
> interfering with each other and writing in the middle of a line. However I
> am not sure, that's the reason of my question. The file was opened with the
> ngx_conf_open_file.
>
> Thanks,
> Antonio
>
> ___
> nginx-devel mailing list
> nginx-devel@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>



-- 




*Regard,Soshnikov Vasily mailto:dedok@gmail.com *
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

ngx_write_fd

2018-03-29 Thread Antonio Nappa 
Hi,

I was wondering what happens with ngx_write_fd function and multiple
workers, I have made some tests and it doesn't look like they are
interfering with each other and writing in the middle of a line. However I
am not sure, that's the reason of my question. The file was opened with the
ngx_conf_open_file.

Thanks,
Antonio
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel