How is the progress to support DTLS

[aperfectman]

Hello team,

I am looking for a loader balancer to support DTLS on UDP and found that
there is experimental DTLS support in specific version 1.13.0 Nginx.
http://nginx.org/patches/dtls/README.txt 

Just curious about the progress of releasing the official feature?  And is
it being supported in Nginx Plus? 

Thanks,
Ted

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

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

Re: [PATCH] HTTP/2: expose function to push single resource to modules

[Ruslan Ermilov]

On Thu, Feb 08, 2018 at 07:48:25PM +, Alessandro Ghedini wrote:
> On Thu, Feb 08, 2018 at 10:00:27PM +0300, Maxim Dounin wrote:
> > On Thu, Feb 08, 2018 at 04:52:59PM +, Alessandro Ghedini wrote:
> > 
> > > # HG changeset patch
> > > # User Alessandro Ghedini 
> > > # Date 1518108716 0
> > > #  Thu Feb 08 16:51:56 2018 +
> > > # Branch expose-push
> > > # Node ID 1bb98b06d5536dfc80a407aabd8d06f9309f8df6
> > > # Parent  a49af443656f2b65ca5de9d8cad5594f44e18ff7
> > > HTTP/2: expose function to push single resource to modules.
> > > 
> > > This makes it possible for 3rd party modules to implement alternative
> > > methods for deciding which resources to push to clients on a per-request
> > > basis (e.g. by parsing HTML from the response body, by using a custom
> > > Link header parser, ...).
> > > 
> > > No functional changes.
> > 
> > Not sure this is a good idea.
> > 
> > You may consider exposing a variable to be used in http2_push 
> > instead.
> 
> Right, the problem is that as far as I can tell http2_push only supports a
> single resource, even when a variable is used, so it wouldn't be possible to
> push multiple resources without specifying multiple http2_push directives,
> each with its own variable, and even then you'd only have a fixed number of
> resources that can be pushed, which wouldn't work well when the number of
> resources changes depending on each request/response.
> 
> So in the end exposing the internal functions to modules seemed better than
> just trying to make http2_push support multiple resources per directive,
> which would add complexity to NGINX itself rather than the external modules
> (though I can do that if you think it would be a better solution).

We've also considered adding support for the X-Accel-Push header, but
decided not to implement it at this time.  If implemented, there could
be multiple X-Accel-Push headers in the proxied response.
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: [PATCH] HTTP/2: copy additional headers in the pushed requests

[Ruslan Ermilov]

On Thu, Feb 08, 2018 at 08:04:57PM +, Alessandro Ghedini wrote:
> On Thu, Feb 08, 2018 at 10:18:54PM +0300, Maxim Dounin wrote:
> > Hello!
> > 
> > On Thu, Feb 08, 2018 at 05:07:49PM +, Alessandro Ghedini wrote:
> > 
> > > On Thu, Feb 08, 2018 at 05:04:58PM +, Alessandro Ghedini wrote:
> > > > # HG changeset patch
> > > > # User Alessandro Ghedini 
> > > > # Date 1518109032 0
> > > > #  Thu Feb 08 16:57:12 2018 +
> > > > # Branch push-copy-headers
> > > > # Node ID 4f7f42e6d13add2ab0c7a9654472bb74085181d1
> > > > # Parent  a49af443656f2b65ca5de9d8cad5594f44e18ff7
> > > > HTTP/2: copy additional headers in the pushed requests.
> > > > 
> > > > To ensure pushed requests are processed consistently with the original
> > > > client request, some headers need to be copied from the original request
> > > > into the pushed one.
> > > > 
> > > > The headers currently copied are User-Agent, Accept, Accept-Language and
> > > > Accept-Encoding.
> > > 
> > > So, I'm not quite sure if this is the correct way to go about doing this, 
> > > but
> > > I think the issue is real and worth fixing, so I'd be happy to implement 
> > > this
> > > differently if you have alternative ideas.
> > 
> > Could you please elaborate more on "the issue is real"?
> 
> Right, sorry. Essentially the problem is that origins may generate a different
> responses dependning on these headers, and a pushed request may be processed
> inconsistently from the original request if these headers are different (say,
> stupid example, if the client requests a specific language, the main request
> may get a response in one language, and the pushed one in another).
> 
> Additionally things like compression wouldn't work for pushed requests, which
> is not optimal.
> 
> There are of course other headers that could influence the origin's response,
> but this somewhat minimal list of standard headers seemed like a good start.
> 
> FWIW, other server push implementations like Apache's mod_http2, h2o (used
> in production by Fastly) and Cloudflare's closed-source implementation, all
> behave like this, and have done so for years, without any apparent issue.

Akamai copies User-Agent and Accept-Encoding, but sets "Accept: */*",
and doesn't copy/set Accept-Language, on pushes requests:
https://http2.akamai.com

Pushing "Accept: */* looks redundant, as
https://tools.ietf.org/html/rfc7231#section-5.3.2
says that "A request without any Accept header field implies that the
user agent will accept any media type in response.".

h2o seems to blindly copy the headers you mentioned, including Accept
from the original request, which is obviously wrong:

: [  1.239] recv (stream_id=13) :method: GET
: [  1.239] recv (stream_id=13) :scheme: https
: [  1.239] recv (stream_id=13) :authority: h2o.examp1e.net
: [  1.239] recv (stream_id=13) :path: /search/jquery-1.9.1.min.js
: [  1.239] recv (stream_id=13) accept: text/html
: [  1.239] recv (stream_id=13) accept-encoding: [...]
: [  1.239] recv (stream_id=13) user-agent: [...]
: [  1.239] recv (stream_id=13) accept-language: [...]
: [  1.239] recv PUSH_PROMISE frame 

Re: [PATCH] HTTP/2: copy additional headers in the pushed requests

[Piotr Sikora via nginx-devel]

Hi Ruslan,

> http header: "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36"
> http header: "Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8"
> http header: "Accept-Encoding: gzip, deflate, br"
> http header: "Accept-Language:
ru,en-US;q=0.9,en;q=0.8,zh-TW;q=0.7,zh;q=0.6"
> (...)
> http header: "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36"
> http header: "Accept: image/webp,image/apng,image/*,*/*;q=0.8"
> http header: "Accept-Encoding: gzip, deflate, br"
> http header: "Accept-Language:
ru,en-US;q=0.9,en;q=0.8,zh-TW;q=0.7,zh;q=0.6"

> http header: "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13;
rv:52.0) Gecko/20100101 Firefox/52.0"
> http header: "Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"
> http header: "Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3"
> http header: "Accept-Encoding: gzip, deflate"
> (...)
> http header: "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13;
rv:52.0) Gecko/20100101 Firefox/52.0"
> http header: "Accept: */*"
> http header: "Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3"
> http header: "Accept-Encoding: gzip, deflate"

In both examples, User-Agent, Accept-Encoding and Accept-Language are the
same, and Accept is (an extension-specific?) subset of the "/" request,
which proves that this is in fact a good idea.

Best regards,
Piotr Sikora
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: [PATCH] HTTP/2: copy additional headers in the pushed requests

[Alessandro Ghedini]

On Thu, Feb 08, 2018 at 10:28:34PM +0300, Ruslan Ermilov wrote:
> On Thu, Feb 08, 2018 at 05:07:49PM +, Alessandro Ghedini wrote:
> > On Thu, Feb 08, 2018 at 05:04:58PM +, Alessandro Ghedini wrote:
> > > # HG changeset patch
> > > # User Alessandro Ghedini 
> > > # Date 1518109032 0
> > > #  Thu Feb 08 16:57:12 2018 +
> > > # Branch push-copy-headers
> > > # Node ID 4f7f42e6d13add2ab0c7a9654472bb74085181d1
> > > # Parent  a49af443656f2b65ca5de9d8cad5594f44e18ff7
> > > HTTP/2: copy additional headers in the pushed requests.
> > > 
> > > To ensure pushed requests are processed consistently with the original
> > > client request, some headers need to be copied from the original request
> > > into the pushed one.
> > > 
> > > The headers currently copied are User-Agent, Accept, Accept-Language and
> > > Accept-Encoding.
> > 
> > So, I'm not quite sure if this is the correct way to go about doing this, 
> > but
> > I think the issue is real and worth fixing, so I'd be happy to implement 
> > this
> > differently if you have alternative ideas.
> 
> I don't think this is a good idea.  Copying Accept is definitely
> a bad idea.  If this is at all needed, this should be implemented
> as an "http2_push_header  " directive, but then it
> could not be made dependent on the pushed resource.

So, I guess this could be implemented so you can have something like:

http2_push_header User-Agent $http_user_agent
...

This would work for me, and indeed is much better than just having a static
list of headers like I did. I'll look into making a patch if this is something
you'd be happy with.

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

Re: [PATCH] HTTP/2: copy additional headers in the pushed requests

[Alessandro Ghedini]

On Thu, Feb 08, 2018 at 10:18:54PM +0300, Maxim Dounin wrote:
> Hello!
> 
> On Thu, Feb 08, 2018 at 05:07:49PM +, Alessandro Ghedini wrote:
> 
> > On Thu, Feb 08, 2018 at 05:04:58PM +, Alessandro Ghedini wrote:
> > > # HG changeset patch
> > > # User Alessandro Ghedini 
> > > # Date 1518109032 0
> > > #  Thu Feb 08 16:57:12 2018 +
> > > # Branch push-copy-headers
> > > # Node ID 4f7f42e6d13add2ab0c7a9654472bb74085181d1
> > > # Parent  a49af443656f2b65ca5de9d8cad5594f44e18ff7
> > > HTTP/2: copy additional headers in the pushed requests.
> > > 
> > > To ensure pushed requests are processed consistently with the original
> > > client request, some headers need to be copied from the original request
> > > into the pushed one.
> > > 
> > > The headers currently copied are User-Agent, Accept, Accept-Language and
> > > Accept-Encoding.
> > 
> > So, I'm not quite sure if this is the correct way to go about doing this, 
> > but
> > I think the issue is real and worth fixing, so I'd be happy to implement 
> > this
> > differently if you have alternative ideas.
> 
> Could you please elaborate more on "the issue is real"?

Right, sorry. Essentially the problem is that origins may generate a different
responses dependning on these headers, and a pushed request may be processed
inconsistently from the original request if these headers are different (say,
stupid example, if the client requests a specific language, the main request
may get a response in one language, and the pushed one in another).

Additionally things like compression wouldn't work for pushed requests, which
is not optimal.

There are of course other headers that could influence the origin's response,
but this somewhat minimal list of standard headers seemed like a good start.

FWIW, other server push implementations like Apache's mod_http2, h2o (used
in production by Fastly) and Cloudflare's closed-source implementation, all
behave like this, and have done so for years, without any apparent issue.

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

Re: [PATCH] HTTP/2: expose function to push single resource to modules

[Alessandro Ghedini]

On Thu, Feb 08, 2018 at 10:00:27PM +0300, Maxim Dounin wrote:
> Hello!
> 
> On Thu, Feb 08, 2018 at 04:52:59PM +, Alessandro Ghedini wrote:
> 
> > # HG changeset patch
> > # User Alessandro Ghedini 
> > # Date 1518108716 0
> > #  Thu Feb 08 16:51:56 2018 +
> > # Branch expose-push
> > # Node ID 1bb98b06d5536dfc80a407aabd8d06f9309f8df6
> > # Parent  a49af443656f2b65ca5de9d8cad5594f44e18ff7
> > HTTP/2: expose function to push single resource to modules.
> > 
> > This makes it possible for 3rd party modules to implement alternative
> > methods for deciding which resources to push to clients on a per-request
> > basis (e.g. by parsing HTML from the response body, by using a custom
> > Link header parser, ...).
> > 
> > No functional changes.
> 
> Not sure this is a good idea.
> 
> You may consider exposing a variable to be used in http2_push 
> instead.

Right, the problem is that as far as I can tell http2_push only supports a
single resource, even when a variable is used, so it wouldn't be possible to
push multiple resources without specifying multiple http2_push directives,
each with its own variable, and even then you'd only have a fixed number of
resources that can be pushed, which wouldn't work well when the number of
resources changes depending on each request/response.

So in the end exposing the internal functions to modules seemed better than
just trying to make http2_push support multiple resources per directive,
which would add complexity to NGINX itself rather than the external modules
(though I can do that if you think it would be a better solution).

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

Re: HTTP/2 server push

[Ruslan Ermilov]

On Thu, Feb 08, 2018 at 08:45:50AM -0500, beatnut wrote:
> Hi everyone,
> According to the roadmap https://trac.nginx.org/nginx/roadmap server push
> will show up in a few days.

It's been committed today and will be available in the next release.

> My question is :
> How to mitigate problem when we are pushing resources already being in the
> cache for example pushed earlier ?

Apache has this mechanism:
http://httpd.apache.org/docs/2.4/mod/mod_http2.html#h2pushdiarysize

But it doesn't mitigate a problem of wasted bandwidth with HTTP/2
push if a client opens a new connection, or a server is restarted.

> Do i have to make some workaround using cookies or nginx can hadle that kind
> of situation?

Happy you now also know that HTTP/2 push is mostly a myth when it
comes to performance improvement.  In my opinion, it only has very
limited application.
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: [PATCH] HTTP/2: copy additional headers in the pushed requests

[Ruslan Ermilov]

On Thu, Feb 08, 2018 at 05:07:49PM +, Alessandro Ghedini wrote:
> On Thu, Feb 08, 2018 at 05:04:58PM +, Alessandro Ghedini wrote:
> > # HG changeset patch
> > # User Alessandro Ghedini 
> > # Date 1518109032 0
> > #  Thu Feb 08 16:57:12 2018 +
> > # Branch push-copy-headers
> > # Node ID 4f7f42e6d13add2ab0c7a9654472bb74085181d1
> > # Parent  a49af443656f2b65ca5de9d8cad5594f44e18ff7
> > HTTP/2: copy additional headers in the pushed requests.
> > 
> > To ensure pushed requests are processed consistently with the original
> > client request, some headers need to be copied from the original request
> > into the pushed one.
> > 
> > The headers currently copied are User-Agent, Accept, Accept-Language and
> > Accept-Encoding.
> 
> So, I'm not quite sure if this is the correct way to go about doing this, but
> I think the issue is real and worth fixing, so I'd be happy to implement this
> differently if you have alternative ideas.

I don't think this is a good idea.  Copying Accept is definitely
a bad idea.  If this is at all needed, this should be implemented
as an "http2_push_header  " directive, but then it
could not be made dependent on the pushed resource.

For example, a simple HTML with "img src" results in the following
Accept values for HTML, and then for image (Chrome and Firefox):

http request line: "GET / HTTP/1.1"
http header: "Host: 127.0.0.1:8000"
http header: "Connection: keep-alive"
http header: "Cache-Control: max-age=0"
http header: "Upgrade-Insecure-Requests: 1"
http header: "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) 
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36"
http header: "Accept: 
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8"
http header: "Accept-Encoding: gzip, deflate, br"
http header: "Accept-Language: ru,en-US;q=0.9,en;q=0.8,zh-TW;q=0.7,zh;q=0.6"

http request line: "GET /foo.jpg HTTP/1.1"
http header: "Host: 127.0.0.1:8000"
http header: "Connection: keep-alive"
http header: "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) 
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36"
http header: "Accept: image/webp,image/apng,image/*,*/*;q=0.8"
http header: "Referer: http://127.0.0.1:8000/;
http header: "Accept-Encoding: gzip, deflate, br"
http header: "Accept-Language: ru,en-US;q=0.9,en;q=0.8,zh-TW;q=0.7,zh;q=0.6"


http request line: "GET / HTTP/1.1"
http header: "Host: 127.0.0.1:8000"
http header: "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; 
rv:52.0) Gecko/20100101 Firefox/52.0"
http header: "Accept: 
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"
http header: "Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3"
http header: "Accept-Encoding: gzip, deflate"
http header: "Connection: keep-alive"
http header: "Upgrade-Insecure-Requests: 1"

http request line: "GET /foo.jpg HTTP/1.1"
http header: "Host: 127.0.0.1:8000"
http header: "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; 
rv:52.0) Gecko/20100101 Firefox/52.0"
http header: "Accept: */*"
http header: "Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3"
http header: "Accept-Encoding: gzip, deflate"
http header: "Referer: http://127.0.0.1:8000/;
http header: "Connection: keep-alive"
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: [PATCH] HTTP/2: copy additional headers in the pushed requests

[Maxim Dounin]

Hello!

On Thu, Feb 08, 2018 at 05:07:49PM +, Alessandro Ghedini wrote:

> On Thu, Feb 08, 2018 at 05:04:58PM +, Alessandro Ghedini wrote:
> > # HG changeset patch
> > # User Alessandro Ghedini 
> > # Date 1518109032 0
> > #  Thu Feb 08 16:57:12 2018 +
> > # Branch push-copy-headers
> > # Node ID 4f7f42e6d13add2ab0c7a9654472bb74085181d1
> > # Parent  a49af443656f2b65ca5de9d8cad5594f44e18ff7
> > HTTP/2: copy additional headers in the pushed requests.
> > 
> > To ensure pushed requests are processed consistently with the original
> > client request, some headers need to be copied from the original request
> > into the pushed one.
> > 
> > The headers currently copied are User-Agent, Accept, Accept-Language and
> > Accept-Encoding.
> 
> So, I'm not quite sure if this is the correct way to go about doing this, but
> I think the issue is real and worth fixing, so I'd be happy to implement this
> differently if you have alternative ideas.

Could you please elaborate more on "the issue is real"?

AFAIR, use of content negotiation with HTTP/2 push isn't a good 
idea[1], and trying to copy some headers might only make things 
more complicated and harder to debug.

[1] https://lists.w3.org/Archives/Public/public-webapps-github/2017Sep/1492.html

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

Re: [PATCH] HTTP/2: expose function to push single resource to modules

[Maxim Dounin]

Hello!

On Thu, Feb 08, 2018 at 04:52:59PM +, Alessandro Ghedini wrote:

> # HG changeset patch
> # User Alessandro Ghedini 
> # Date 1518108716 0
> #  Thu Feb 08 16:51:56 2018 +
> # Branch expose-push
> # Node ID 1bb98b06d5536dfc80a407aabd8d06f9309f8df6
> # Parent  a49af443656f2b65ca5de9d8cad5594f44e18ff7
> HTTP/2: expose function to push single resource to modules.
> 
> This makes it possible for 3rd party modules to implement alternative
> methods for deciding which resources to push to clients on a per-request
> basis (e.g. by parsing HTML from the response body, by using a custom
> Link header parser, ...).
> 
> No functional changes.

Not sure this is a good idea.

You may consider exposing a variable to be used in http2_push 
instead.

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

Re: [PATCH] HTTP/2: copy additional headers in the pushed requests

[Alessandro Ghedini]

On Thu, Feb 08, 2018 at 05:04:58PM +, Alessandro Ghedini wrote:
> # HG changeset patch
> # User Alessandro Ghedini 
> # Date 1518109032 0
> #  Thu Feb 08 16:57:12 2018 +
> # Branch push-copy-headers
> # Node ID 4f7f42e6d13add2ab0c7a9654472bb74085181d1
> # Parent  a49af443656f2b65ca5de9d8cad5594f44e18ff7
> HTTP/2: copy additional headers in the pushed requests.
> 
> To ensure pushed requests are processed consistently with the original
> client request, some headers need to be copied from the original request
> into the pushed one.
> 
> The headers currently copied are User-Agent, Accept, Accept-Language and
> Accept-Encoding.

So, I'm not quite sure if this is the correct way to go about doing this, but
I think the issue is real and worth fixing, so I'd be happy to implement this
differently if you have alternative ideas.

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

[PATCH] HTTP/2: copy additional headers in the pushed requests

[Alessandro Ghedini]

# HG changeset patch
# User Alessandro Ghedini 
# Date 1518109032 0
#  Thu Feb 08 16:57:12 2018 +
# Branch push-copy-headers
# Node ID 4f7f42e6d13add2ab0c7a9654472bb74085181d1
# Parent  a49af443656f2b65ca5de9d8cad5594f44e18ff7
HTTP/2: copy additional headers in the pushed requests.

To ensure pushed requests are processed consistently with the original
client request, some headers need to be copied from the original request
into the pushed one.

The headers currently copied are User-Agent, Accept, Accept-Language and
Accept-Encoding.

diff -r a49af443656f -r 4f7f42e6d13a src/http/v2/ngx_http_v2.c
--- a/src/http/v2/ngx_http_v2.c Thu Feb 08 12:11:30 2018 +0300
+++ b/src/http/v2/ngx_http_v2.c Thu Feb 08 16:57:12 2018 +
@@ -156,6 +156,8 @@
 ngx_str_t *value);
 static ngx_int_t ngx_http_v2_parse_authority(ngx_http_request_t *r,
 ngx_str_t *value);
+static ngx_int_t ngx_http_v2_copy_header(ngx_http_request_t *r,
+ngx_table_elt_t *hdr);
 static ngx_int_t ngx_http_v2_construct_request_line(ngx_http_request_t *r);
 static ngx_int_t ngx_http_v2_cookie(ngx_http_request_t *r,
 ngx_http_v2_header_t *header);
@@ -2516,7 +2518,8 @@
 
 ngx_int_t
 ngx_http_v2_push_stream(ngx_http_v2_connection_t *h2c, ngx_uint_t depend,
-size_t request_length, ngx_str_t *path, ngx_str_t *authority)
+size_t request_length, ngx_str_t *path, ngx_str_t *authority,
+ngx_http_headers_in_t *headers_in)
 {
 ngx_int_t  rc;
 ngx_str_t  value;
@@ -2605,6 +2608,34 @@
 goto error;
 }
 
+rc = ngx_http_v2_copy_header(r, headers_in->user_agent);
+
+if (rc != NGX_OK) {
+goto error;
+}
+
+#if (NGX_HTTP_HEADERS)
+rc = ngx_http_v2_copy_header(r, headers_in->accept);
+
+if (rc != NGX_OK) {
+goto error;
+}
+
+rc = ngx_http_v2_copy_header(r, headers_in->accept_language);
+
+if (rc != NGX_OK) {
+goto error;
+}
+#endif
+
+#if (NGX_HTTP_GZIP)
+rc = ngx_http_v2_copy_header(r, headers_in->accept_encoding);
+
+if (rc != NGX_OK) {
+goto error;
+}
+#endif
+
 fc->write->handler = ngx_http_v2_run_request_handler;
 ngx_post_event(fc->write, _posted_events);
 
@@ -3479,6 +3510,63 @@
 
 
 static ngx_int_t
+ngx_http_v2_copy_header(ngx_http_request_t *r, ngx_table_elt_t *hdr)
+{
+ngx_table_elt_t*h;
+ngx_http_header_t  *hh;
+ngx_http_core_main_conf_t  *cmcf;
+
+if (hdr == NULL) {
+return NGX_OK;
+}
+
+h = ngx_list_push(>headers_in.headers);
+if (h == NULL) {
+return NGX_ERROR;
+}
+
+h->hash = hdr->hash;
+
+h->key.len = hdr->key.len;
+
+h->key.data = ngx_pnalloc(r->stream->pool, h->key.len + 1);
+if (h->key.data == NULL) {
+h->hash = 0;
+return NGX_ERROR;
+}
+
+(void) ngx_cpystrn(h->key.data, hdr->key.data, h->key.len + 1);
+
+h->value.len = hdr->value.len;
+
+h->value.data = ngx_pnalloc(r->stream->pool, h->value.len + 1);
+if (h->key.data == NULL) {
+h->hash = 0;
+return NGX_ERROR;
+}
+
+(void) ngx_cpystrn(h->value.data, hdr->value.data, h->value.len + 1);
+
+h->lowcase_key = h->key.data;
+
+cmcf = ngx_http_get_module_main_conf(r, ngx_http_core_module);
+
+hh = ngx_hash_find(>headers_in_hash, h->hash,
+   h->lowcase_key, h->key.len);
+
+if (hh == NULL) {
+return NGX_ERROR;
+}
+
+if (hh->handler(r, h, hh->offset) != NGX_OK) {
+return NGX_ERROR;
+}
+
+return NGX_OK;
+}
+
+
+static ngx_int_t
 ngx_http_v2_construct_request_line(ngx_http_request_t *r)
 {
 u_char  *p;
diff -r a49af443656f -r 4f7f42e6d13a src/http/v2/ngx_http_v2.h
--- a/src/http/v2/ngx_http_v2.h Thu Feb 08 12:11:30 2018 +0300
+++ b/src/http/v2/ngx_http_v2.h Thu Feb 08 16:57:12 2018 +
@@ -285,7 +285,7 @@
 
 ngx_int_t ngx_http_v2_push_stream(ngx_http_v2_connection_t *h2c,
 ngx_uint_t depend, size_t request_length, ngx_str_t *path,
-ngx_str_t *authority);
+ngx_str_t *authority, ngx_http_headers_in_t *headers_in);
 
 void ngx_http_v2_close_stream(ngx_http_v2_stream_t *stream, ngx_int_t rc);
 
diff -r a49af443656f -r 4f7f42e6d13a src/http/v2/ngx_http_v2_filter_module.c
--- a/src/http/v2/ngx_http_v2_filter_module.c   Thu Feb 08 12:11:30 2018 +0300
+++ b/src/http/v2/ngx_http_v2_filter_module.c   Thu Feb 08 16:57:12 2018 +
@@ -972,6 +972,34 @@
   + authority->len
   + 1;
 
+if (r->headers_in.user_agent) {
+len += 1 + NGX_HTTP_V2_INT_OCTETS + r->headers_in.user_agent->key.len
+ + NGX_HTTP_V2_INT_OCTETS + 
r->headers_in.user_agent->value.len;
+}
+
+#if (NGX_HTTP_HEADERS)
+if (r->headers_in.accept) {
+len += 1 + NGX_HTTP_V2_INT_OCTETS + r->headers_in.accept->key.len
+ + NGX_HTTP_V2_INT_OCTETS + r->headers_in.accept->value.len;
+}
+
+if (r->headers_in.accept_language) {
+len += 1 + NGX_HTTP_V2_INT_OCTETS
+   

[PATCH] HTTP/2: expose function to push single resource to modules

[Alessandro Ghedini]

# HG changeset patch
# User Alessandro Ghedini 
# Date 1518108716 0
#  Thu Feb 08 16:51:56 2018 +
# Branch expose-push
# Node ID 1bb98b06d5536dfc80a407aabd8d06f9309f8df6
# Parent  a49af443656f2b65ca5de9d8cad5594f44e18ff7
HTTP/2: expose function to push single resource to modules.

This makes it possible for 3rd party modules to implement alternative
methods for deciding which resources to push to clients on a per-request
basis (e.g. by parsing HTML from the response body, by using a custom
Link header parser, ...).

No functional changes.

diff -r a49af443656f -r 1bb98b06d553 src/http/v2/ngx_http_v2.h
--- a/src/http/v2/ngx_http_v2.h Thu Feb 08 12:11:30 2018 +0300
+++ b/src/http/v2/ngx_http_v2.h Thu Feb 08 16:51:56 2018 +
@@ -304,6 +304,9 @@
 size_t ngx_http_v2_huff_encode(u_char *src, size_t len, u_char *dst,
 ngx_uint_t lower);
 
+ngx_int_t ngx_http_v2_push_resource(ngx_http_request_t *r, ngx_str_t *path,
+ngx_str_t *authority);
+
 
 #define ngx_http_v2_prefix(bits)  ((1 << (bits)) - 1)
 
diff -r a49af443656f -r 1bb98b06d553 src/http/v2/ngx_http_v2_filter_module.c
--- a/src/http/v2/ngx_http_v2_filter_module.c   Thu Feb 08 12:11:30 2018 +0300
+++ b/src/http/v2/ngx_http_v2_filter_module.c   Thu Feb 08 16:51:56 2018 +
@@ -62,8 +62,6 @@
 
 
 static ngx_int_t ngx_http_v2_push_resources(ngx_http_request_t *r);
-static ngx_int_t ngx_http_v2_push_resource(ngx_http_request_t *r,
-ngx_str_t *path, ngx_str_t *authority);
 
 static u_char *ngx_http_v2_string_encode(u_char *dst, u_char *src, size_t len,
 u_char *tmp, ngx_uint_t lower);
@@ -903,7 +901,7 @@
 }
 
 
-static ngx_int_t
+ngx_int_t
 ngx_http_v2_push_resource(ngx_http_request_t *r, ngx_str_t *path,
 ngx_str_t *authority)
 {
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

HTTP/2 server push

[beatnut]

Hi everyone,
According to the roadmap https://trac.nginx.org/nginx/roadmap server push
will show up in a few days. My question is :
How to mitigate problem when we are pushing resources already being in the
cache for example pushed earlier ?
Do i have to make some workaround using cookies or nginx can hadle that kind
of situation?

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

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

[nginx] HTTP/2: fixed build with -Werror=unused-but-set-variable.

[Ruslan Ermilov]

details:   http://hg.nginx.org/nginx/rev/a49af443656f
branches:  
changeset: 7202:a49af443656f
user:  Ruslan Ermilov 
date:  Thu Feb 08 12:11:30 2018 +0300
description:
HTTP/2: fixed build with -Werror=unused-but-set-variable.

diffstat:

 src/http/v2/ngx_http_v2_filter_module.c |  13 +++--
 1 files changed, 3 insertions(+), 10 deletions(-)

diffs (33 lines):

diff -r 641306096f5b -r a49af443656f src/http/v2/ngx_http_v2_filter_module.c
--- a/src/http/v2/ngx_http_v2_filter_module.c   Thu Feb 08 09:55:03 2018 +0300
+++ b/src/http/v2/ngx_http_v2_filter_module.c   Thu Feb 08 12:11:30 2018 +0300
@@ -688,18 +688,11 @@ ngx_http_v2_push_resources(ngx_http_requ
 ngx_str_t   path, authority;
 ngx_uint_t  i, push;
 ngx_table_elt_t   **h;
-ngx_connection_t   *fc;
-ngx_http_v2_stream_t   *stream;
 ngx_http_v2_loc_conf_t *h2lcf;
-ngx_http_v2_connection_t   *h2c;
 ngx_http_complex_value_t   *pushes;
 
-fc = r->connection;
-
-ngx_log_debug0(NGX_LOG_DEBUG_HTTP, fc->log, 0, "http2 push resources");
-
-stream = r->stream;
-h2c = stream->connection;
+ngx_log_debug0(NGX_LOG_DEBUG_HTTP, r->connection->log, 0,
+   "http2 push resources");
 
 ngx_str_null();
 
@@ -744,7 +737,7 @@ ngx_http_v2_push_resources(ngx_http_requ
 
 for (i = 0; i < r->headers_out.link.nelts; i++) {
 
-ngx_log_debug1(NGX_LOG_DEBUG_HTTP, fc->log, 0,
+ngx_log_debug1(NGX_LOG_DEBUG_HTTP, r->connection->log, 0,
"http2 parse link: \"%V\"", [i]->value);
 
 start = h[i]->value.data;
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: [IE] localhost works but server_name times out!

[Francis Daly]

On Wed, Feb 07, 2018 at 09:56:15PM -0500, Credo wrote:

Hi there,

> If by dns record, you mean uwsgi_pass, then yea, I'm sure. Otherwise
> localhost wouldn't work either, but it does.

Your client (browser) should resolve the name "www.example.com" to an
IP address that corresponds to the nginx server; and all network control
devices (remote firewalls, local iptables or the like) should allow the
traffic get from your client to the nginx IP:port.

All of that has to happen before nginx gets involved.

Since you can access http://localhost/, but not http://www.example.com/,
the first thing to check is whether your client tries to talk to your
nginx when it asks for http://www.example.com/.

If it doesn't, you must fix things outside of nginx so that it does.

f
-- 
Francis Dalyfran...@daoine.org
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: Allow and Deny IP's

[Francis Daly]

On Wed, Feb 07, 2018 at 07:28:37PM +0100, Ph. Gras wrote:

Hi there,

> >> location ~* wp-login\.php$ {
> > 
> >> 185.124.153.168 - - [05/Feb/2018:21:36:12 +0100] "GET /wp-login.php 
> >> HTTP/1.1" 200 1300 "-" "Mozilla/5.0 (Windows NT 6.0; rv:34.0) 
> >> Gecko/20100101 Firefox/34.0"
> > 
> >> Me too :-(
> > 
> > Have you any reason to believe that this location is used to handle this 
> > request?
> 
> Yes, and this especially since before, it worked as expected :-(

I see in other mail that that has become fixed -- probably this location
was not being used for this request, owing to an earlier "location ~
php", or something else that was changed since it had been working before.

> > $ nginx -T | grep 'server\|location'
> > 
> > will possibly give a useful hint in that direction.
> 
> # nginx -T | grep "www.example.com/wp-login.php"
> nginx: invalid option: "T"

I actually meant literally "grep 'server\|location'", to show the
server{} blocks (and server_name directives) and the location directives
in your config, which might be enough to show which location{} is used
for one request.

But your nginx version is from before "-T" was added, so you would have
to look in the config file (and any include:d files) directly, and there
isn't a simple one-liner to do that.

And now that it works for you, it is not important any more :-)

f
-- 
Francis Dalyfran...@daoine.org
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx