New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 10 users

Issue metadata

Status: Fixed
Closed: Nov 2015
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug

Sign in to add a comment

Issue 557197: Enable HTTP/2 over NPN (with OpenSSL).

Reported by, Nov 17 2015 Project Member

Issue description

Since OpenSSL 1.0.2 deployment is still scarce (for example, not in Ubuntu LTS until release 16.04), and earlier OpenSSL versions do not support ALPN, HTTP/2 should be re-enabled in Chromium even when using NPN (with OpenSSL: it never was disabled with NSS).

See  issue 527066  for motivation of disabling HTTP/2 over NPN in the first place.

Comment 1 by, Nov 17 2015

This seems like a serious change in policy and our previous public commitments and openness. I'm not sure this is justified, but certainly requires greater transparency than a crbug.

Comment 2 by, Nov 17 2015


Comment 3 by, Nov 17 2015

Other options:
- See if Ubuntu is willing to backport ALPN, especially given that we're hoping to remove NPN.
- See if OpenSSL is willing to backport it to 1.0.1 (which they really should have done from the beginning; it's a completely trivial feature), especially given that we're hoping to remove NPN.
- Carry on with deprecations as we'd already committed to publicly.

The nice thing about removing NPN or SPDY is that it cannot break sites. Of course, it can hurt performance, and that is significant. But it means the criteria for going forward with things can be looser. And it reaffirms our commitment to the standardization process, that we're willing to deprecate our experiments in favor of the standardized ones.

Comment 4 by, Nov 17 2015

This is specifically about H2 negotiation with NPN, and may be a temporary
stopgap to keep the behavior.

We still plan to deprecate both NPN and SPDY altogether.

Agree that more then a crbug is required if we change that policy.

Comment 5 by, Nov 17 2015

Re: #1.  We announced our plans to deprecate SPDY/3.1 and NPN early 2016, and we are on good track to keep to that schedule.  There is no change in commitment policy.

Re: #3.  I agree that encouraging package maintainers to backport ALPN should be considered parallel to our deprecation plans.

Note that Nginx now supports HTTP/2 *instead of* SPDY/3.1, not alongside with it.  If system administrators do not have easy access to ALPN-capable OpenSSL (and many of them won't until next April), and if Chromium refuses to support HTTP/2 over NPN, then they will delay upgrading Nginx, which hurts HTTP/2 adoption.

Comment 6 by, Nov 17 2015

Mmm, that's fair. That nginx requires things happen in lock-step probably means that constraint doesn't help things.

But timing based on Ubuntu's release date won't actually do much. People aren't going to upgrade to an LTS overnight when it gets released. I think the few months extra buffer between when M48 would release and the April LTS are meaningless.

It sounds like our only option here is to push for a backport. Then a few more months of buffer might make sense for the time period needed for folks to take those updates.

Comment 7 by, Nov 20 2015

 Issue 559216  has been merged into this issue.

Comment 8 by, Nov 20 2015

As the reporter of 559216, how can I fix my webserver so that I don't have to wait for this? Do I need to update something to do with openssl etc? What should I be doing that I'm not?

Comment 9 by, Nov 20 2015

Re #8: In short, you need ALPN support in your webserver, which is provided by OpenSSL 1.0.2 but not 1.0.1.  See if your distribution provides an OpenSSL 1.0.2 backport package, or if you can compile vanilla OpenSSL 1.0.2, or if you can use your distro's OpenSSL 1.0.1 source, patch in ALPN support, and build a package, or if you can upgrade your distro to a more recent release that has OpenSSL 1.0.2.  I'm sorry, I know none of these is easy.

Comment 10 by, Nov 20 2015

No that's great, thank you!

Comment 11 by, Nov 21 2015

Just FYI, this is not fun on Debian :) Does this need to happen now when supporting this is such a pain?

Comment 13 Deleted

Comment 14 by, Nov 23 2015

Hi Bence,

this CL had introduced massive redness of Valgrind and MSan bots.
See and

All of these uses of uninitialized variables seem to originate from, which reads uninitialized params_.enable_npn
I couldn't figure out what should the default value of enable_npn be (and whether it's correct that it's not always initialized from the session dependencies), so I'm inclined towards reverting.

Comment 15 by, Nov 23 2015

Project Member
The following revision refers to this bug:

commit e038f1dc42693ffe6fc47c719a9051b9e0a05651
Author: glider <>
Date: Mon Nov 23 11:29:03 2015

Revert of Re-enable HTTP/2 over NPN (for OpenSSL). (patchset #3 id:40001 of )

Reason for revert:
The CL has introduced massive MSan and Valgrind reports, see the bug.

BUG= 557197 

Original issue's description:
> Re-enable HTTP/2 over NPN (for OpenSSL).
> BUG= 557197 
> Committed:
> Cr-Commit-Position: refs/heads/master@{#361053},
BUG= 557197 

Review URL:

Cr-Commit-Position: refs/heads/master@{#361088}


Comment 16 by Deleted ...@, Nov 24 2015

Hi all
We're in in awkward position WRT NPN/ALPN as CentOS 7 (which we're hosting nginx under) has no ALPN-capable openssl package. The ideal from our perspective, is that NPN support under chromium for NPN and H2 is available until perhaps mid next year, by which time we should be able to resolve the issue. Without this we're going to have zero H2 usage at the BBC which is a pretty big deal for us as we serve a reasonable chunk of trafiic and is a real shame as we've been putting a lot of effort into TLS everywhere and to not have H2's benefits would be a blow to that work.

Comment 18 by, Nov 30 2015

Labels: Merge-Request-48
Requesting merge of to M48 (2564).

Comment 19 by, Nov 30 2015

Labels: -Merge-Request-48 Merge-Approved-48 Hotlist-Merge-Approved
Congrats your change is auto-approved for M48 (branch: 2564)

Comment 21 by, Nov 30 2015

Status: Fixed

Comment 22 by, Dec 1 2015

Project Member
The following revision refers to this bug:

commit d9824e642c5db4aae9331c232421fc8ff30859c0
Author: Bence Béky <>
Date: Mon Nov 30 14:05:45 2015

Sign in to add a comment