ALPN support for HTTP/2

[mxmo0rhuhn]

Would it be possible to include a OpenSSL version >= 1.0.2 to make ALPN work?
Due to the official documentation it's needed for HTTP/2 over TLS:

Note that accepting HTTP/2 connections over TLS requires the “Application-Layer Protocol Negotiation” (ALPN) TLS extension support, which is available only since OpenSSL version 1.0.2.

The current version in the nginx:1.9.12 image is:

$ openssl version
OpenSSL 1.0.1k 8 Jan 2015

[thresheek]

Note that HTTP/2 right now works via NPN, which does not require openssl 1.0.2 and most browsers still support it at the time of writing.

The support for ALPN will arrive in nginx:latest as soon as Debian Stretch with openssl 1.0.2 is released.
If you really need ALPN with nginx official, please use the alpine variant, as it has openssl 1.0.2.

[mxmo0rhuhn]

Thanks a lot for the fast reply!
I will have a look at the alpine variant.

[hermansje]

Starting May 15th, Chrome will drop support for SPDY and NPN [1].
Does this mean everyone wanting something better than HTTP/1.1 using this image should switch to the Alpine version?

[1] https://blog.chromium.org/2016/02/transitioning-from-spdy-to-http2.html

[thresheek]

Not really, you can still use HTTPS.

[teohhanhui]

I agree with this: https://plus.google.com/+AmbroosVaes/posts/TLJJ41Ghg9R

There does't seem to be any workaround for now except building OpenSSL ourselves (is it easy?) or switching to the Alpine variant (which is alien to most people).

[hermansje]

I tried the Alpine version and HTTP/2 and ALPN are working. I only had to change the FROM instruction in my Dockerfile to reference an Alpine version.

[thresheek]

@teohhanhui indeed. There are a lots of people with the same arguments like you linked, but apparently Google does not care at all (not that is surprising).

One of the workarounds for nginx could be using Ubuntu 16.04 as a base image, but I'm not really sure how much breakage that will cause - I would expect many people actually do FROM nginx:latest and use debian-specific things there. I'm also sure HTTP2 does not justify that breakage - after all, browsers will still show your website.

[fruitl00p]

I was looking into this today and found out (by trial and error) that the alpine and debian versions differ in their end result due to this...

I would expect that nginx:1.10 and nginx:1.10-alpine wouldnt differ that much (i.e. the openssl-version) but it did... One might argue that since we're talking about an nginx image that both would lead to the same build...? (but smaller images et al) But due to differing openssl-versions the actual nginx build is also very different... (one supporting APLN whilst the other doesnt) that seems weird to me... (or atleast should be documented somewhere? i.e. which openssl version its built with i.e.)

(BTW this also seems to go for the built in modules enabled between the two versions of the image?)

[CWSpear]

Now that it's long past May 15th (I guess the switch to turn it off actually came a couple weeks after?), HTTP/2 is not working on a lot of sites where it was working...

Being a nice feature that has some nice performance gains on many sites, it'd be great if we could come up with a good solution for the official nginx image.

Having a community-audited image with the recommended version of OpenSSL seems like a very good idea. (Isn't that part of why Google dropped support for older versions?)

[thresheek]

It looks like openssl-1.0.2 is available in jessie-backports. I'll have it running for a couple of weeks on my infra and then will consider it being included in the nginx official image.

Scratch that actually, as it will require nginx to be recompiled against backports version of openssl. Won't work.

[Foorack]

Any update on this?

[teohhanhui]

Use the Alpine variant. It's smaller too.

…

On 12 Dec 2016 02:31, "Foorack" ***@***.***> wrote: Any update on this? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#76 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAhf6-DGwzSQ-_5HWHTvEygVN9wha_wVks5rHEGHgaJpZM4H68nw> .