date:20180307

Re: location blocks, and if conditions in server context

2018-03-07 Thread Lucas Rolff

Hi peter,

I generate configs already using a template engine (more specific Laravel 
Blade), so creating the functionality in the template is easy, however, I 
generally don’t like having server blocks that can be 100s of lines because of 
repeating things

I don’t know the internals of nginx fully, how it uses memory when storing 
configs, but I would assume that inheritance is better than duplication in 
terms of memory usage.

I’m just wondering if there’s a way I can avoid the if condition within the 
location blocks.

- lucas

Get Outlook for iOS

From: nginx  on behalf of Peter Booth 

Sent: Wednesday, March 7, 2018 11:08:40 PM
To: nginx@nginx.org
Subject: Re: location blocks, and if conditions in server context

I agree that avoiding if is a good thing. But avoiding duplication isn’t always 
good.

Have you considered a model where your configuration file is generated with a 
templating engine? The input file that you modify to add/remove/change 
configurations could be free of duplication but the conf file that nginx reads 
could be concrete and verbose

Sent from my iPhone

On Mar 7, 2018, at 11:55, Lucas Rolff 
> wrote:

Hi guys,

I have a few hundred nginx zones, where I try to remove as much duplicate code 
as possible, and inherit as much as possible to prevent nginx from consuming 
memory (and also to keep things clean).

However I came across something today, that I don’t know how to get my head 
around without duplicating code, even within a single server context.

I have a set of distributed nginx servers, all these requires SSL certificates, 
where I use Let’s Encrypt to do this.
When doing the Let’s Encrypt validation, it uses a path such as 
/.well-known/acme-challenge/

For this, I made a location block such as:

location ~* /.well-known {
proxy_pass http://letsencrypt.validation.backend.com$request_uri;
}

Basically, I proxy_pass to the backend where I actually run the acme client – 
works great.

However, I have an option to force a redirect from http to https, and I’ve 
implemented that by doing an if condition on the server block level (so not 
within a location):

if ($sslproxy_protocol = "http") {
return 301 https://$host$request_uri;
}

This means I have something like:

1: location ~* /.well-known
2: if condition doing redirect if protocol is http
3: location /
4: location /api
5: location /test

All my templates include 1 to 3, and *might* have additional locations.
I’ve decided to not put e.g. location /api inside the location / - because 
there’s things I don’t want to inherit, thus keeping them at the same “level”, 
and not a location context inside a location context.
Things I don’t want to inherit, is stuff such as headers, max_ranges directive 
etc.

My issue is – because of this if condition that does the redirect to https – it 
also applies to my location ~* /.well-known – thus causing a redirect, and I 
want to prevent this, since it breaks the Let’s Encrypt validation (they do not 
accept 301 redirects).

A solution would be to move the if condition into each location block that I 
want to have redirected, but then I start repeating myself 1, 2 or even 10 
times – which I don’t wanna do.

Is there a smart way without adding too much complexity, which is still 
super-fast (I know if is evil) ?

A config example is seen below:

server {
listen  80;
listen  443 ssl http2;

server_name secure.domain.com;

access_log /var/log/nginx/secure.domain.com main;

location ~* /.well-known {
proxy_pass http://letsencrypt.validation.backend.com$request_uri;
}

if ($sslproxy_protocol = "http") {
return 301 https://$host$request_uri;
}

location / {

expires 10m;
etag off;

proxy_ignore_client_abort   on;
proxy_intercept_errors  on;
proxy_next_upstream error timeout invalid_header;
proxy_ignore_headersSet-Cookie Vary X-Accel-Expires Expires 
Cache-Control;
more_clear_headers  Set-Cookie Cookie Upgrade;

proxy_cache one;
proxy_cache_min_uses1;
proxy_cache_lockoff;
proxy_cache_use_stale   error timeout invalid_header updating 
http_500 http_502 http_503 http_504;

proxy_cache_valid 200   10m;
proxy_cache_valid any   1m;

proxy_cache_revalidate  on;
proxy_ssl_server_name   on;

include /etc/nginx/server.conf;

proxy_set_header Host backend-host.com;

proxy_cache_key"http://backend-host.com-1-$request_uri;;
proxy_pass http://backend-host.com$request_uri;

proxy_redirect  off;

Re: location blocks, and if conditions in server context

2018-03-07 Thread Peter Booth

I agree that avoiding if is a good thing. But avoiding duplication isn’t always 
good. 

Have you considered a model where your configuration file is generated with a 
templating engine? The input file that you modify to add/remove/change 
configurations could be free of duplication but the conf file that nginx reads 
could be concrete and verbose 

Sent from my iPhone

> On Mar 7, 2018, at 11:55, Lucas Rolff  wrote:
> 
> Hi guys,
>  
> I have a few hundred nginx zones, where I try to remove as much duplicate 
> code as possible, and inherit as much as possible to prevent nginx from 
> consuming memory (and also to keep things clean).
> 
> However I came across something today, that I don’t know how to get my head 
> around without duplicating code, even within a single server context.
>  
> I have a set of distributed nginx servers, all these requires SSL 
> certificates, where I use Let’s Encrypt to do this.
> When doing the Let’s Encrypt validation, it uses a path such as 
> /.well-known/acme-challenge/
>  
> For this, I made a location block such as:
>  
> location ~* /.well-known {
> proxy_pass http://letsencrypt.validation.backend.com$request_uri;
> }
>  
> Basically, I proxy_pass to the backend where I actually run the acme client – 
> works great.
>  
> However, I have an option to force a redirect from http to https, and I’ve 
> implemented that by doing an if condition on the server block level (so not 
> within a location):
>  
> if ($sslproxy_protocol = "http") {
> return 301 https://$host$request_uri;
> }
>  
> This means I have something like:
>  
> 1: location ~* /.well-known
> 2: if condition doing redirect if protocol is http
> 3: location /
> 4: location /api
> 5: location /test
>  
> All my templates include 1 to 3, and *might* have additional locations.
> I’ve decided to not put e.g. location /api inside the location / - because 
> there’s things I don’t want to inherit, thus keeping them at the same 
> “level”, and not a location context inside a location context.
> Things I don’t want to inherit, is stuff such as headers, max_ranges 
> directive etc.
>  
> My issue is – because of this if condition that does the redirect to https – 
> it also applies to my location ~* /.well-known – thus causing a redirect, and 
> I want to prevent this, since it breaks the Let’s Encrypt validation (they do 
> not accept 301 redirects).
>  
> A solution would be to move the if condition into each location block that I 
> want to have redirected, but then I start repeating myself 1, 2 or even 10 
> times – which I don’t wanna do.
>  
> Is there a smart way without adding too much complexity, which is still 
> super-fast (I know if is evil) ?
>  
> A config example is seen below:
>  
> server {
> listen  80;
> listen  443 ssl http2;
>  
> server_name secure.domain.com;
>  
> access_log /var/log/nginx/secure.domain.com main;
>  
> location ~* /.well-known {
> proxy_pass http://letsencrypt.validation.backend.com$request_uri;
> }
>  
> if ($sslproxy_protocol = "http") {
> return 301 https://$host$request_uri;
> }
>  
> location / {
>  
> expires 10m;
> etag off;
>  
> proxy_ignore_client_abort   on;
> proxy_intercept_errors  on;
> proxy_next_upstream error timeout invalid_header;
> proxy_ignore_headersSet-Cookie Vary X-Accel-Expires Expires 
> Cache-Control;
> more_clear_headers  Set-Cookie Cookie Upgrade;
>  
> proxy_cache one;
> proxy_cache_min_uses1;
> proxy_cache_lockoff;
> proxy_cache_use_stale   error timeout invalid_header updating 
> http_500 http_502 http_503 http_504;
>  
> proxy_cache_valid 200   10m;
> proxy_cache_valid any   1m;
>  
> proxy_cache_revalidate  on;
> proxy_ssl_server_name   on;
>  
> include /etc/nginx/server.conf;
>  
> proxy_set_header Host backend-host.com;
>  
> proxy_cache_key"http://backend-host.com-1-$request_uri;;
> proxy_pass http://backend-host.com$request_uri;
>  
> proxy_redirect  off;
> }
> }
>  
> Thank you in advance!
>  
> Best Regards,
> Lucas Rolff
> ___
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Make nginx ignore unresolvable upstream server host names during reload or boot up

2018-03-07 Thread shivramg94

Hi,

I have multiple upstream servers configured in an upstream block in my nginx
configuration. 

upstream example2 {
server example2.service.example.com:8001;
server example1.service.example.com:8002;
}

server {
   listen 80;
   server_name example2.com;
   location / {
  proxy_set_header X-Forwarded-For $remote_addr;
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_pass http://example2/;
   }
}

When i try to reload Nginx and at that time if one of my upstream servers
(say example2.service.example.com) is not DNS resolvable, then the reload
fails with an error "host not found in upstream".

Is there any way we can ask nginx to ignore such unresolvable host names or
rather configure Nginx to resolve these upstream server host names at run
time instead of resolving it during the boot up or reload process?

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?2,278968,278968#msg-278968

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

Re: thread_pool in Windows

2018-03-07 Thread Ruslan Ermilov

On Tue, Mar 06, 2018 at 10:38:21PM -0500, Sergey Sandler wrote:
> Thank you, Valentin.
> 
> There is something I am missing. Please see the start of the error.log
> below,
> 
> 2018/03/04 14:05:50 [notice] 5144#9212: using the "select" event method
> 2018/03/04 14:05:50 [notice] 5144#9212: using the "select" event method
> 2018/03/04 14:05:50 [notice] 5144#9212: nginx/1.12.2
> 2018/03/04 14:05:50 [notice] 5144#9212: nginx/1.12.2
> 2018/03/04 14:05:50 [info] 5144#9212: OS: 260200 build:9200, "", suite:300,
> type:1
> 2018/03/04 14:05:50 [notice] 5144#9212: start worker processes
> 2018/03/04 14:05:50 [notice] 5144#9212: start worker processes
> 2018/03/04 14:05:50 [notice] 5144#9212: start worker process 13648
> 2018/03/04 14:05:50 [notice] 5144#9212: start worker process 13648
> 2018/03/04 14:05:51 [notice] 13648#4924: nginx/1.12.2
> 2018/03/04 14:05:51 [notice] 13648#4924: nginx/1.12.2
> 2018/03/04 14:05:51 [info] 13648#4924: OS: 260200 build:9200, "", suite:300,
> type:1
> 2018/03/04 14:05:51 [notice] 13648#4924: create thread 17496
> 2018/03/04 14:05:51 [notice] 13648#4924: create thread 17496
> 2018/03/04 14:05:51 [notice] 13648#4924: create thread 16328
> 2018/03/04 14:05:51 [notice] 13648#4924: create thread 16328
> 2018/03/04 14:05:51 [notice] 13648#4924: create thread 13940
> 2018/03/04 14:05:51 [notice] 13648#4924: create thread 13940
> 
> There is a single process (worker_processes  1 in the nginx.conf), with
> seemingly three threads (not sure why the lines in the log file are
> duplicated). Is the purpose of the additional threads to read static files
> (from the server)?

nginx for Windows only uses one worker process, and inside it only
one worker thread is created.  You see three threads because it also
creates two other threads for cache_manager and cache_loader (these
are implemented as separate processes on UNIX):

if (ngx_create_thread(, ngx_worker_thread, NULL, log) != 0) {
goto failed;
}

if (ngx_create_thread(, ngx_cache_manager_thread, NULL, log) != 0) {
goto failed;
}

if (ngx_create_thread(, ngx_cache_loader_thread, NULL, log) != 0) {
goto failed;
}


See also:

http://nginx.org/en/docs/windows.html#known_issues (item #1)
http://nginx.org/en/docs/windows.html#possible_future_enhancements (item #3)
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: newbie: nginx rtmp module

2018-03-07 Thread neuronetv

thankyou for your feedback gariac.

# nginx - V
nginx: invalid option: "V"

I think this may be because I have the 'yum install' version of nginx and
not the tarball. TIA for any further ideas.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?2,278950,278952#msg-278952

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

Re: newbie: nginx rtmp module

2018-03-07 Thread Gary

Grrr that swift keyboard. There is no space before the capital V. 

nginx -V

I'd be surprised if that command doesn't work now. Any reason you haven't 
upgraded to Centos 7?



  Original Message  
From: nginx-fo...@forum.nginx.org
Sent: March 7, 2018 1:53 AM
To: nginx@nginx.org
Reply-to: nginx@nginx.org
Subject: Re: newbie: nginx rtmp module

thankyou for your feedback gariac.

# nginx - V
nginx: invalid option: "V"

I think this may be because I have the 'yum install' version of nginx and
not the tarball. TIA for any further ideas.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?2,278950,278952#msg-278952

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

Re: Routing based on ALPN

2018-03-07 Thread Wiktor Kwapisiewicz via nginx

> below is the initial version of patch that creates the
> "$ssl_preread_alpn_protocols" variable; the content is a comma-separated
> list of protocols, sent by client in ALPN extension, if present.
> 
> Any feedback is appretiated.
> 

I have just tested this patch and can confirm it's working perfectly fine.

The patch was applied against this commit: 
https://github.com/nginx/nginx/commit/83dceda8688fcba6da9fd12f6480606563d7b7a3
And I was using LibreSSL.

I've set up three upstream servers for tests, two using node.js (HTTPS) and one 
Prosody (XMPP server):

map $ssl_preread_alpn_protocols $upstream {
default node1;
"h2,http/1.1" node2;
"xmpp-client" prosody;
}

Curling with no ALPN correctly returns answer from node1:

> curl -k -i --no-alpn https://docker.local
HTTP/1.1 200 OK
Date: Wed, 07 Mar 2018 11:24:26 GMT
Connection: keep-alive
Content-Length: 23

Everything works: node1

Curling with default configuration (ALPN: h2,http/1.1) also works:

> curl -k -i https://docker.local
HTTP/1.1 200 OK
Date: Wed, 07 Mar 2018 11:24:43 GMT
Connection: keep-alive
Content-Length: 23

Everything works: node2

Then I tested XMPP by adding an SRV record:

> dig _xmpps-client._tcp.testing.metacode.biz SRV
;; ANSWER SECTION:
_xmpps-client._tcp.testing.metacode.biz. 119 IN SRV 1 1 443 docker.local.

And using Gajim to connect to testing.metacode.biz. It worked.

Nginx (web_1) logs correctly show all connection attempts with ALPN values:

prosody_1  | c2s2564890  info   Client connected
web_1  | 192.168.99.1 xmpp-client [07/Mar/2018:11:21:58 +] TCP 200 2335 
871 1.566
web_1  | 192.168.99.1  [07/Mar/2018:11:24:26 +] TCP 200 1546 327 0.298
web_1  | 192.168.99.1 h2,http/1.1 [07/Mar/2018:11:24:35 +] TCP 200 1539 
262 0.324
web_1  | 192.168.99.1 h2,http/1.1 [07/Mar/2018:11:24:43 +] TCP 200 1539 
262 0.293
prosody_1  | c2s2564890  info   Authenticated 
as wik...@testing.metacode.biz

I've used log_format basic '$remote_addr $ssl_preread_alpn_protocols 
[$time_local] '
 '$protocol $status $bytes_sent $bytes_received '
 '$session_time';

This looks *very good*, thanks for your time!

Kind regards,
Wiktor

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

Re: Routing based on ALPN

2018-03-07 Thread Maxim Konovalov

On 07/03/2018 14:38, Wiktor Kwapisiewicz via nginx wrote:
[...]
> This looks *very good*, thanks for your time!

Thanks for your testing, Wiktor.

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

Re: newbie: nginx rtmp module

2018-03-07 Thread Gary

nginx - V
will show what modules are installed. 

  Original Message  
From: nginx-fo...@forum.nginx.org
Sent: March 7, 2018 12:24 AM
To: nginx@nginx.org
Reply-to: nginx@nginx.org
Subject: newbie: nginx rtmp module

I'm running centos 6 and installed nginx using 'yum install nginx'. Videos
are not working and I don't know whether I have the rtmp module or not. Here
is the text from the yum install:

Installing:
collectd-nginx x86_64   
4.10.9-4.el6 epel 14 k
munin-nginx    noarch   
2.0.33-1.el6 epel 26 k
nginx  x86_64   
1.10.2-1.el6 epel    462 k
nginx-all-modules  noarch   
1.10.2-1.el6 epel    7.7 k
nginx-filesystem   noarch   
1.10.2-1.el6 epel    8.5 k

It says 'nginx-all-modules'  on the 4th line but no other clue. Is there a
way to tell if I have the rtmp module? If I don't have it is there a way to
install it?

extra info: I did previously install nginx using the nginx-1.13.9.tar.gz
tarball and also installed the nginx rtmp module from the git clone and it

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

location blocks, and if conditions in server context

2018-03-07 Thread Lucas Rolff

Hi guys,

I have a few hundred nginx zones, where I try to remove as much duplicate code 
as possible, and inherit as much as possible to prevent nginx from consuming 
memory (and also to keep things clean).

However I came across something today, that I don’t know how to get my head 
around without duplicating code, even within a single server context.

I have a set of distributed nginx servers, all these requires SSL certificates, 
where I use Let’s Encrypt to do this.
When doing the Let’s Encrypt validation, it uses a path such as 
/.well-known/acme-challenge/

For this, I made a location block such as:

location ~* /.well-known {
proxy_pass http://letsencrypt.validation.backend.com$request_uri;
}

Basically, I proxy_pass to the backend where I actually run the acme client – 
works great.

However, I have an option to force a redirect from http to https, and I’ve 
implemented that by doing an if condition on the server block level (so not 
within a location):

if ($sslproxy_protocol = "http") {
return 301 https://$host$request_uri;
}

This means I have something like:

1: location ~* /.well-known
2: if condition doing redirect if protocol is http
3: location /
4: location /api
5: location /test

All my templates include 1 to 3, and *might* have additional locations.
I’ve decided to not put e.g. location /api inside the location / - because 
there’s things I don’t want to inherit, thus keeping them at the same “level”, 
and not a location context inside a location context.
Things I don’t want to inherit, is stuff such as headers, max_ranges directive 
etc.

My issue is – because of this if condition that does the redirect to https – it 
also applies to my location ~* /.well-known – thus causing a redirect, and I 
want to prevent this, since it breaks the Let’s Encrypt validation (they do not 
accept 301 redirects).

A solution would be to move the if condition into each location block that I 
want to have redirected, but then I start repeating myself 1, 2 or even 10 
times – which I don’t wanna do.

Is there a smart way without adding too much complexity, which is still 
super-fast (I know if is evil) ?

A config example is seen below:

server {
listen  80;
listen  443 ssl http2;

server_name secure.domain.com;

access_log /var/log/nginx/secure.domain.com main;

location ~* /.well-known {
proxy_pass http://letsencrypt.validation.backend.com$request_uri;
}

if ($sslproxy_protocol = "http") {
return 301 https://$host$request_uri;
}

location / {

expires 10m;
etag off;

proxy_ignore_client_abort   on;
proxy_intercept_errors  on;
proxy_next_upstream error timeout invalid_header;
proxy_ignore_headersSet-Cookie Vary X-Accel-Expires Expires 
Cache-Control;
more_clear_headers  Set-Cookie Cookie Upgrade;

proxy_cache one;
proxy_cache_min_uses1;
proxy_cache_lockoff;
proxy_cache_use_stale   error timeout invalid_header updating 
http_500 http_502 http_503 http_504;

proxy_cache_valid 200   10m;
proxy_cache_valid any   1m;

proxy_cache_revalidate  on;
proxy_ssl_server_name   on;

include /etc/nginx/server.conf;

proxy_set_header Host backend-host.com;

proxy_cache_key"http://backend-host.com-1-$request_uri;;
proxy_pass http://backend-host.com$request_uri;

proxy_redirect  off;
}
}

Thank you in advance!

Best Regards,
Lucas Rolff
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: [PATCH] HTTP/2: make http2 server support http1

2018-03-07 Thread Haitao Lv

Here is a more simple patch. And the temp buffer has also been freed.

Please make your comments. Thanks.


diff --git a/src/http/ngx_http_request.c b/src/http/ngx_http_request.c
index 89cfe77a..d97952bc 100644
--- a/src/http/ngx_http_request.c
+++ b/src/http/ngx_http_request.c
@@ -17,6 +17,10 @@ static ssize_t 
ngx_http_read_request_header(ngx_http_request_t *r);
 static ngx_int_t ngx_http_alloc_large_header_buffer(ngx_http_request_t *r,
 ngx_uint_t request_line);
 
+#if (NGX_HTTP_V2)
+static void ngx_http_wait_v2_preface_handler(ngx_event_t *rev);
+#endif
+
 static ngx_int_t ngx_http_process_header_line(ngx_http_request_t *r,
 ngx_table_elt_t *h, ngx_uint_t offset);
 static ngx_int_t ngx_http_process_unique_header_line(ngx_http_request_t *r,
@@ -321,7 +325,7 @@ ngx_http_init_connection(ngx_connection_t *c)
 
 #if (NGX_HTTP_V2)
 if (hc->addr_conf->http2) {
-rev->handler = ngx_http_v2_init;
+rev->handler = ngx_http_wait_v2_preface_handler;
 }
 #endif
 
@@ -377,6 +381,110 @@ ngx_http_init_connection(ngx_connection_t *c)
 }
 
 
+#if (NGX_HTTP_V2)
+static void
+ngx_http_wait_v2_preface_handler(ngx_event_t *rev)
+{
+size_t size;
+ssize_tn;
+ngx_buf_t *b;
+ngx_connection_t  *c;
+static const u_charpreface[] = "PRI";
+
+c = rev->data;
+size = sizeof(preface) - 1;
+
+ngx_log_debug0(NGX_LOG_DEBUG_HTTP, c->log, 0,
+"http wait h2 preface handler");
+
+if (rev->timedout) {
+ngx_log_error(NGX_LOG_INFO, c->log, NGX_ETIMEDOUT, "client timed out");
+ngx_http_close_connection(c);
+return;
+}
+
+if (c->close) {
+ngx_http_close_connection(c);
+return;
+}
+
+b = c->buffer;
+
+if (b == NULL) {
+b = ngx_create_temp_buf(c->pool, size);
+if (b == NULL) {
+ngx_http_close_connection(c);
+return;
+}
+
+c->buffer = b;
+
+} else if (b->start == NULL) {
+
+b->start = ngx_palloc(c->pool, size);
+if (b->start == NULL) {
+ngx_http_close_connection(c);
+return;
+}
+
+b->pos = b->start;
+b->last = b->start;
+b->end = b->last + size;
+}
+
+n = c->recv(c, b->last, size);
+
+if (n == NGX_AGAIN) {
+
+if (!rev->timer_set) {
+ngx_add_timer(rev, c->listening->post_accept_timeout);
+ngx_reusable_connection(c, 1);
+}
+
+if (ngx_handle_read_event(rev, 0) != NGX_OK) {
+ngx_http_close_connection(c);
+return;
+}
+
+/*
+ * We are trying to not hold c->buffer's memory for an idle connection.
+ */
+
+if (ngx_pfree(c->pool, b->start) == NGX_OK) {
+b->start = NULL;
+}
+
+return;
+}
+
+if (n == NGX_ERROR) {
+ngx_http_close_connection(c);
+return;
+}
+
+if (n == 0) {
+ngx_log_error(NGX_LOG_INFO, c->log, 0,
+  "client closed connection");
+ngx_http_close_connection(c);
+return;
+}
+
+b->last += n;
+
+if (b->last == b->end) {
+/* b will be freed in ngx_http_v2_init/ngx_http_wait_request_handler */
+
+if (ngx_strncmp(b->start, preface, size) == 0) {
+ngx_http_v2_init(rev);
+} else {
+rev->handler = ngx_http_wait_request_handler;
+ngx_http_wait_request_handler(rev);
+}
+}
+}
+#endif
+
+
 static void
 ngx_http_wait_request_handler(ngx_event_t *rev)
 {
@@ -430,6 +538,22 @@ ngx_http_wait_request_handler(ngx_event_t *rev)
 b->pos = b->start;
 b->last = b->start;
 b->end = b->last + size;
+} else {
+
+p = ngx_palloc(c->pool, size);
+if (p == NULL) {
+ngx_http_close_connection(c);
+return;
+}
+
+n = b->last - b->start;
+ngx_memcpy(p, b->start, n);
+ngx_pfree(c->pool, b->start);
+
+b->start = p;
+b->pos = b->start;
+b->last = b->start + n;
+b->end = b->last + size;
 }
 
 n = c->recv(c, b->last, size);
diff --git a/src/http/v2/ngx_http_v2.c b/src/http/v2/ngx_http_v2.c
index d9df0f90..e36bf382 100644
--- a/src/http/v2/ngx_http_v2.c
+++ b/src/http/v2/ngx_http_v2.c
@@ -231,6 +231,8 @@ static ngx_http_v2_parse_header_t  
ngx_http_v2_parse_headers[] = {
 void
 ngx_http_v2_init(ngx_event_t *rev)
 {
+size_t size;
+ngx_buf_t *b;
 ngx_connection_t  *c;
 ngx_pool_cleanup_t*cln;
 ngx_http_connection_t *hc;
@@ -262,6 +264,23 @@ ngx_http_v2_init(ngx_event_t *rev)
 return;
 }
 
+b = c->buffer;
+
+if (b != NULL) {
+size = b->last - b->start;
+
+if (size > h2mcf->recv_buffer_size) {
+size = h2mcf->recv_buffer_size;
+}
+
+ngx_memcpy(h2mcf->recv_buffer, b->start, size);

Re: [PATCH] HTTP/2: make http2 server support http1

2018-03-07 Thread Haitao Lv

Sorry for disturbing. But I have to fix a buffer overflow bug.
Here is the latest patch.

Sorry. But please make your comments. Thank you.


diff --git a/src/http/ngx_http_request.c b/src/http/ngx_http_request.c
index 89cfe77a..c51d8ace 100644
--- a/src/http/ngx_http_request.c
+++ b/src/http/ngx_http_request.c
@@ -17,6 +17,10 @@ static ssize_t 
ngx_http_read_request_header(ngx_http_request_t *r);
 static ngx_int_t ngx_http_alloc_large_header_buffer(ngx_http_request_t *r,
 ngx_uint_t request_line);
 
+#if (NGX_HTTP_V2)
+static void ngx_http_wait_v2_preface_handler(ngx_event_t *rev);
+#endif
+
 static ngx_int_t ngx_http_process_header_line(ngx_http_request_t *r,
 ngx_table_elt_t *h, ngx_uint_t offset);
 static ngx_int_t ngx_http_process_unique_header_line(ngx_http_request_t *r,
@@ -321,7 +325,7 @@ ngx_http_init_connection(ngx_connection_t *c)
 
 #if (NGX_HTTP_V2)
 if (hc->addr_conf->http2) {
-rev->handler = ngx_http_v2_init;
+rev->handler = ngx_http_wait_v2_preface_handler;
 }
 #endif
 
@@ -377,6 +381,110 @@ ngx_http_init_connection(ngx_connection_t *c)
 }
 
 
+#if (NGX_HTTP_V2)
+static void
+ngx_http_wait_v2_preface_handler(ngx_event_t *rev)
+{
+size_t size;
+ssize_tn;
+ngx_buf_t *b;
+ngx_connection_t  *c;
+static const u_charpreface[] = "PRI";
+
+c = rev->data;
+size = sizeof(preface) - 1;
+
+ngx_log_debug0(NGX_LOG_DEBUG_HTTP, c->log, 0,
+"http wait h2 preface handler");
+
+if (rev->timedout) {
+ngx_log_error(NGX_LOG_INFO, c->log, NGX_ETIMEDOUT, "client timed out");
+ngx_http_close_connection(c);
+return;
+}
+
+if (c->close) {
+ngx_http_close_connection(c);
+return;
+}
+
+b = c->buffer;
+
+if (b == NULL) {
+b = ngx_create_temp_buf(c->pool, size);
+if (b == NULL) {
+ngx_http_close_connection(c);
+return;
+}
+
+c->buffer = b;
+
+} else if (b->start == NULL) {
+
+b->start = ngx_palloc(c->pool, size);
+if (b->start == NULL) {
+ngx_http_close_connection(c);
+return;
+}
+
+b->pos = b->start;
+b->last = b->start;
+b->end = b->last + size;
+}
+
+n = c->recv(c, b->last, b->end - b->last);
+
+if (n == NGX_AGAIN) {
+
+if (!rev->timer_set) {
+ngx_add_timer(rev, c->listening->post_accept_timeout);
+ngx_reusable_connection(c, 1);
+}
+
+if (ngx_handle_read_event(rev, 0) != NGX_OK) {
+ngx_http_close_connection(c);
+return;
+}
+
+/*
+ * We are trying to not hold c->buffer's memory for an idle connection.
+ */
+
+if (ngx_pfree(c->pool, b->start) == NGX_OK) {
+b->start = NULL;
+}
+
+return;
+}
+
+if (n == NGX_ERROR) {
+ngx_http_close_connection(c);
+return;
+}
+
+if (n == 0) {
+ngx_log_error(NGX_LOG_INFO, c->log, 0,
+  "client closed connection");
+ngx_http_close_connection(c);
+return;
+}
+
+b->last += n;
+
+if (b->last == b->end) {
+/* b will be freed in ngx_http_v2_init/ngx_http_wait_request_handler */
+
+if (ngx_strncmp(b->start, preface, size) == 0) {
+ngx_http_v2_init(rev);
+} else {
+rev->handler = ngx_http_wait_request_handler;
+ngx_http_wait_request_handler(rev);
+}
+}
+}
+#endif
+
+
 static void
 ngx_http_wait_request_handler(ngx_event_t *rev)
 {
@@ -430,6 +538,22 @@ ngx_http_wait_request_handler(ngx_event_t *rev)
 b->pos = b->start;
 b->last = b->start;
 b->end = b->last + size;
+} else {
+
+p = ngx_palloc(c->pool, size);
+if (p == NULL) {
+ngx_http_close_connection(c);
+return;
+}
+
+n = b->last - b->start;
+ngx_memcpy(p, b->start, n);
+ngx_pfree(c->pool, b->start);
+
+b->start = p;
+b->pos = b->start;
+b->last = b->start + n;
+b->end = b->last + size;
 }
 
 n = c->recv(c, b->last, size);
diff --git a/src/http/v2/ngx_http_v2.c b/src/http/v2/ngx_http_v2.c
index d9df0f90..e36bf382 100644
--- a/src/http/v2/ngx_http_v2.c
+++ b/src/http/v2/ngx_http_v2.c
@@ -231,6 +231,8 @@ static ngx_http_v2_parse_header_t  
ngx_http_v2_parse_headers[] = {
 void
 ngx_http_v2_init(ngx_event_t *rev)
 {
+size_t size;
+ngx_buf_t *b;
 ngx_connection_t  *c;
 ngx_pool_cleanup_t*cln;
 ngx_http_connection_t *hc;
@@ -262,6 +264,23 @@ ngx_http_v2_init(ngx_event_t *rev)
 return;
 }
 
+b = c->buffer;
+
+if (b != NULL) {
+size = b->last - b->start;
+
+if (size > h2mcf->recv_buffer_size) {
+size = h2mcf->recv_buffer_size;
+}
+
+

Re: [nginx] Improved code readablity.

2018-03-07 Thread Junwang Zhao

I'm a little bit confused why the diffs are equal to each other,
ASAICS, the changed code removed the effect of 'flags'?

Can you explain a little bit since I just began to read the code base :)

2018-03-07 23:29 GMT+08:00 Ruslan Ermilov :
> details:   http://hg.nginx.org/nginx/rev/0b1eb40de6da
> branches:
> changeset: 7226:0b1eb40de6da
> user:  Ruslan Ermilov 
> date:  Wed Mar 07 18:28:12 2018 +0300
> description:
> Improved code readablity.
>
> No functional changes.
>
> diffstat:
>
>  src/http/ngx_http_variables.c |  8 ++--
>  src/stream/ngx_stream_variables.c |  8 ++--
>  2 files changed, 12 insertions(+), 4 deletions(-)
>
> diffs (50 lines):
>
> diff -r e80930e5e422 -r 0b1eb40de6da src/http/ngx_http_variables.c
> --- a/src/http/ngx_http_variables.c Mon Mar 05 21:35:13 2018 +0300
> +++ b/src/http/ngx_http_variables.c Wed Mar 07 18:28:12 2018 +0300
> @@ -429,7 +429,9 @@ ngx_http_add_variable(ngx_conf_t *cf, ng
>  return NULL;
>  }
>
> -v->flags &= flags | ~NGX_HTTP_VAR_WEAK;
> +if (!(flags & NGX_HTTP_VAR_WEAK)) {
> +v->flags &= ~NGX_HTTP_VAR_WEAK;
> +}
>
>  return v;
>  }
> @@ -494,7 +496,9 @@ ngx_http_add_prefix_variable(ngx_conf_t
>  return NULL;
>  }
>
> -v->flags &= flags | ~NGX_HTTP_VAR_WEAK;
> +if (!(flags & NGX_HTTP_VAR_WEAK)) {
> +v->flags &= ~NGX_HTTP_VAR_WEAK;
> +}
>
>  return v;
>  }
> diff -r e80930e5e422 -r 0b1eb40de6da src/stream/ngx_stream_variables.c
> --- a/src/stream/ngx_stream_variables.c Mon Mar 05 21:35:13 2018 +0300
> +++ b/src/stream/ngx_stream_variables.c Wed Mar 07 18:28:12 2018 +0300
> @@ -161,7 +161,9 @@ ngx_stream_add_variable(ngx_conf_t *cf,
>  return NULL;
>  }
>
> -v->flags &= flags | ~NGX_STREAM_VAR_WEAK;
> +if (!(flags & NGX_STREAM_VAR_WEAK)) {
> +v->flags &= ~NGX_STREAM_VAR_WEAK;
> +}
>
>  return v;
>  }
> @@ -227,7 +229,9 @@ ngx_stream_add_prefix_variable(ngx_conf_
>  return NULL;
>  }
>
> -v->flags &= flags | ~NGX_STREAM_VAR_WEAK;
> +if (!(flags & NGX_STREAM_VAR_WEAK)) {
> +v->flags &= ~NGX_STREAM_VAR_WEAK;
> +}
>
>  return v;
>  }
> ___
> nginx-devel mailing list
> nginx-devel@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: [nginx] Improved code readablity.

2018-03-07 Thread Ruslan Ermilov

On Thu, Mar 08, 2018 at 08:42:06AM +0800, Junwang Zhao wrote:
> I'm a little bit confused why the diffs are equal to each other,
> ASAICS, the changed code removed the effect of 'flags'?
> 
> Can you explain a little bit since I just began to read the code base :)

"flags | ~NGX_HTTP_VAR_WEAK" would either evaluate to "all bits set"
or "all bits set except NGX_HTTP_VAR_WEAK" if this bit is not set in
"flags".

> 2018-03-07 23:29 GMT+08:00 Ruslan Ermilov :
> > details:   http://hg.nginx.org/nginx/rev/0b1eb40de6da
> > branches:
> > changeset: 7226:0b1eb40de6da
> > user:  Ruslan Ermilov 
> > date:  Wed Mar 07 18:28:12 2018 +0300
> > description:
> > Improved code readablity.
> >
> > No functional changes.
> >
> > diffstat:
> >
> >  src/http/ngx_http_variables.c |  8 ++--
> >  src/stream/ngx_stream_variables.c |  8 ++--
> >  2 files changed, 12 insertions(+), 4 deletions(-)
> >
> > diffs (50 lines):
> >
> > diff -r e80930e5e422 -r 0b1eb40de6da src/http/ngx_http_variables.c
> > --- a/src/http/ngx_http_variables.c Mon Mar 05 21:35:13 2018 +0300
> > +++ b/src/http/ngx_http_variables.c Wed Mar 07 18:28:12 2018 +0300
> > @@ -429,7 +429,9 @@ ngx_http_add_variable(ngx_conf_t *cf, ng
> >  return NULL;
> >  }
> >
> > -v->flags &= flags | ~NGX_HTTP_VAR_WEAK;
> > +if (!(flags & NGX_HTTP_VAR_WEAK)) {
> > +v->flags &= ~NGX_HTTP_VAR_WEAK;
> > +}
> >
> >  return v;
> >  }
> > @@ -494,7 +496,9 @@ ngx_http_add_prefix_variable(ngx_conf_t
> >  return NULL;
> >  }
> >
> > -v->flags &= flags | ~NGX_HTTP_VAR_WEAK;
> > +if (!(flags & NGX_HTTP_VAR_WEAK)) {
> > +v->flags &= ~NGX_HTTP_VAR_WEAK;
> > +}
> >
> >  return v;
> >  }
> > diff -r e80930e5e422 -r 0b1eb40de6da src/stream/ngx_stream_variables.c
> > --- a/src/stream/ngx_stream_variables.c Mon Mar 05 21:35:13 2018 +0300
> > +++ b/src/stream/ngx_stream_variables.c Wed Mar 07 18:28:12 2018 +0300
> > @@ -161,7 +161,9 @@ ngx_stream_add_variable(ngx_conf_t *cf,
> >  return NULL;
> >  }
> >
> > -v->flags &= flags | ~NGX_STREAM_VAR_WEAK;
> > +if (!(flags & NGX_STREAM_VAR_WEAK)) {
> > +v->flags &= ~NGX_STREAM_VAR_WEAK;
> > +}
> >
> >  return v;
> >  }
> > @@ -227,7 +229,9 @@ ngx_stream_add_prefix_variable(ngx_conf_
> >  return NULL;
> >  }
> >
> > -v->flags &= flags | ~NGX_STREAM_VAR_WEAK;
> > +if (!(flags & NGX_STREAM_VAR_WEAK)) {
> > +v->flags &= ~NGX_STREAM_VAR_WEAK;
> > +}
> >
> >  return v;
> >  }
> > ___
> > nginx-devel mailing list
> > nginx-devel@nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-devel
> ___
> nginx-devel mailing list
> nginx-devel@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
> 

-- 
Ruslan Ermilov
Assume stupidity not malice
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: [nginx] Improved code readablity.

2018-03-07 Thread Junwang Zhao

Got it, thanks for your reply :)

On Thu, Mar 8, 2018 at 1:13 PM, Ruslan Ermilov  wrote:
> On Thu, Mar 08, 2018 at 08:42:06AM +0800, Junwang Zhao wrote:
>> I'm a little bit confused why the diffs are equal to each other,
>> ASAICS, the changed code removed the effect of 'flags'?
>>
>> Can you explain a little bit since I just began to read the code base :)
>
> "flags | ~NGX_HTTP_VAR_WEAK" would either evaluate to "all bits set"
> or "all bits set except NGX_HTTP_VAR_WEAK" if this bit is not set in
> "flags".
>
>> 2018-03-07 23:29 GMT+08:00 Ruslan Ermilov :
>> > details:   http://hg.nginx.org/nginx/rev/0b1eb40de6da
>> > branches:
>> > changeset: 7226:0b1eb40de6da
>> > user:  Ruslan Ermilov 
>> > date:  Wed Mar 07 18:28:12 2018 +0300
>> > description:
>> > Improved code readablity.
>> >
>> > No functional changes.
>> >
>> > diffstat:
>> >
>> >  src/http/ngx_http_variables.c |  8 ++--
>> >  src/stream/ngx_stream_variables.c |  8 ++--
>> >  2 files changed, 12 insertions(+), 4 deletions(-)
>> >
>> > diffs (50 lines):
>> >
>> > diff -r e80930e5e422 -r 0b1eb40de6da src/http/ngx_http_variables.c
>> > --- a/src/http/ngx_http_variables.c Mon Mar 05 21:35:13 2018 +0300
>> > +++ b/src/http/ngx_http_variables.c Wed Mar 07 18:28:12 2018 +0300
>> > @@ -429,7 +429,9 @@ ngx_http_add_variable(ngx_conf_t *cf, ng
>> >  return NULL;
>> >  }
>> >
>> > -v->flags &= flags | ~NGX_HTTP_VAR_WEAK;
>> > +if (!(flags & NGX_HTTP_VAR_WEAK)) {
>> > +v->flags &= ~NGX_HTTP_VAR_WEAK;
>> > +}
>> >
>> >  return v;
>> >  }
>> > @@ -494,7 +496,9 @@ ngx_http_add_prefix_variable(ngx_conf_t
>> >  return NULL;
>> >  }
>> >
>> > -v->flags &= flags | ~NGX_HTTP_VAR_WEAK;
>> > +if (!(flags & NGX_HTTP_VAR_WEAK)) {
>> > +v->flags &= ~NGX_HTTP_VAR_WEAK;
>> > +}
>> >
>> >  return v;
>> >  }
>> > diff -r e80930e5e422 -r 0b1eb40de6da src/stream/ngx_stream_variables.c
>> > --- a/src/stream/ngx_stream_variables.c Mon Mar 05 21:35:13 2018 +0300
>> > +++ b/src/stream/ngx_stream_variables.c Wed Mar 07 18:28:12 2018 +0300
>> > @@ -161,7 +161,9 @@ ngx_stream_add_variable(ngx_conf_t *cf,
>> >  return NULL;
>> >  }
>> >
>> > -v->flags &= flags | ~NGX_STREAM_VAR_WEAK;
>> > +if (!(flags & NGX_STREAM_VAR_WEAK)) {
>> > +v->flags &= ~NGX_STREAM_VAR_WEAK;
>> > +}
>> >
>> >  return v;
>> >  }
>> > @@ -227,7 +229,9 @@ ngx_stream_add_prefix_variable(ngx_conf_
>> >  return NULL;
>> >  }
>> >
>> > -v->flags &= flags | ~NGX_STREAM_VAR_WEAK;
>> > +if (!(flags & NGX_STREAM_VAR_WEAK)) {
>> > +v->flags &= ~NGX_STREAM_VAR_WEAK;
>> > +}
>> >
>> >  return v;
>> >  }
>> > ___
>> > nginx-devel mailing list
>> > nginx-devel@nginx.org
>> > http://mailman.nginx.org/mailman/listinfo/nginx-devel
>> ___
>> nginx-devel mailing list
>> nginx-devel@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>>
>
> --
> Ruslan Ermilov
> Assume stupidity not malice
> ___
> nginx-devel mailing list
> nginx-devel@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: Проксирование SSL трафика для клиентов с авторизацией по сертификату

2018-03-07 Thread digger

Решил сделать попроще - авторизацию с помощь сертификата на первом сервере
nginx, а дальше уже без SSL, но по закрытому каналу VPN. Так работает.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,278948,278958#msg-278958

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

[nginx] Improved code readablity.

2018-03-07 Thread Ruslan Ermilov

details:   http://hg.nginx.org/nginx/rev/0b1eb40de6da
branches:  
changeset: 7226:0b1eb40de6da
user:  Ruslan Ermilov 
date:  Wed Mar 07 18:28:12 2018 +0300
description:
Improved code readablity.

No functional changes.

diffstat:

 src/http/ngx_http_variables.c |  8 ++--
 src/stream/ngx_stream_variables.c |  8 ++--
 2 files changed, 12 insertions(+), 4 deletions(-)

diffs (50 lines):

diff -r e80930e5e422 -r 0b1eb40de6da src/http/ngx_http_variables.c
--- a/src/http/ngx_http_variables.c Mon Mar 05 21:35:13 2018 +0300
+++ b/src/http/ngx_http_variables.c Wed Mar 07 18:28:12 2018 +0300
@@ -429,7 +429,9 @@ ngx_http_add_variable(ngx_conf_t *cf, ng
 return NULL;
 }
 
-v->flags &= flags | ~NGX_HTTP_VAR_WEAK;
+if (!(flags & NGX_HTTP_VAR_WEAK)) {
+v->flags &= ~NGX_HTTP_VAR_WEAK;
+}
 
 return v;
 }
@@ -494,7 +496,9 @@ ngx_http_add_prefix_variable(ngx_conf_t 
 return NULL;
 }
 
-v->flags &= flags | ~NGX_HTTP_VAR_WEAK;
+if (!(flags & NGX_HTTP_VAR_WEAK)) {
+v->flags &= ~NGX_HTTP_VAR_WEAK;
+}
 
 return v;
 }
diff -r e80930e5e422 -r 0b1eb40de6da src/stream/ngx_stream_variables.c
--- a/src/stream/ngx_stream_variables.c Mon Mar 05 21:35:13 2018 +0300
+++ b/src/stream/ngx_stream_variables.c Wed Mar 07 18:28:12 2018 +0300
@@ -161,7 +161,9 @@ ngx_stream_add_variable(ngx_conf_t *cf, 
 return NULL;
 }
 
-v->flags &= flags | ~NGX_STREAM_VAR_WEAK;
+if (!(flags & NGX_STREAM_VAR_WEAK)) {
+v->flags &= ~NGX_STREAM_VAR_WEAK;
+}
 
 return v;
 }
@@ -227,7 +229,9 @@ ngx_stream_add_prefix_variable(ngx_conf_
 return NULL;
 }
 
-v->flags &= flags | ~NGX_STREAM_VAR_WEAK;
+if (!(flags & NGX_STREAM_VAR_WEAK)) {
+v->flags &= ~NGX_STREAM_VAR_WEAK;
+}
 
 return v;
 }
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: location blocks, and if conditions in server context

Re: location blocks, and if conditions in server context

Make nginx ignore unresolvable upstream server host names during reload or boot up

Re: thread_pool in Windows

Re: newbie: nginx rtmp module

Re: newbie: nginx rtmp module

Re: Routing based on ALPN

Re: Routing based on ALPN

Re: newbie: nginx rtmp module

location blocks, and if conditions in server context

Re: [PATCH] HTTP/2: make http2 server support http1

Re: [PATCH] HTTP/2: make http2 server support http1

Re: [nginx] Improved code readablity.

Re: [nginx] Improved code readablity.

Re: [nginx] Improved code readablity.

Re: Проксирование SSL трафика для клиентов с авторизацией по сертификату

[nginx] Improved code readablity.

17 matches

Site Navigation

Mail list logo

Footer information