Project: chromium ▼ Issues People Development process History Sign in
New issue
Advanced search Search tips
Issue 557197
Starred by 10 users
Status: Fixed
Owner:
b...@chromium.org
Closed: Nov 2015
Cc:
b...@chromium.org
cbentzel@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug



Sign in to add a comment
 Enable HTTP/2 over NPN (with OpenSSL).
Project Member Reported by b...@chromium.org, Nov 17 2015 Back to list 
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 rsleevi@chromium.org, 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 rsleevi@chromium.org, Nov 17 2015
Cc: cbentzel@chromium.org
Comment 3 by davidben@chromium.org, 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 cbentzel@chromium.org, 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 b...@chromium.org, 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 davidben@chromium.org, 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 b...@chromium.org, Nov 20 2015
Cc: b...@chromium.org
 Issue 559216  has been merged into this issue.
Comment 8 by dan.jenk...@gmail.com, 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 b...@chromium.org, 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 dan.jenk...@gmail.com, Nov 20 2015 
No that's great, thank you!
Comment 11 by dan.jenk...@gmail.com, 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 glider@chromium.org, Nov 23 2015 
Hi Bence,

this CL had introduced massive redness of Valgrind and MSan bots.
See http://build.chromium.org/p/chromium.memory.fyi/builders/Linux%20Tests%20%28valgrind%29%281%29/builds/44632/steps/memory%20test%3A%20net/logs/stdio and http://build.chromium.org/p/chromium.memory.fyi/builders/Linux%20MSan%20Tests/builds/11670/steps/net_unittests/logs/stdio

All of these uses of uninitialized variables seem to originate from http_network_session.cc:334, 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.
Project Member Comment 15 by bugdroid1@chromium.org, Nov 23 2015 
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e038f1dc42693ffe6fc47c719a9051b9e0a05651

commit e038f1dc42693ffe6fc47c719a9051b9e0a05651
Author: glider <glider@chromium.org>
Date: Mon Nov 23 11:29:03 2015

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

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: https://crrev.com/0eb771aa98ba2bd4db0e2b82241afe8f5760c32e
> Cr-Commit-Position: refs/heads/master@{#361053}

TBR=cbentzel@chromium.org,bnc@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= 557197 

Review URL: https://codereview.chromium.org/1472743002

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

[modify] http://crrev.com/e038f1dc42693ffe6fc47c719a9051b9e0a05651/net/http/http_network_session.cc
[modify] http://crrev.com/e038f1dc42693ffe6fc47c719a9051b9e0a05651/net/http/http_network_transaction.h
[modify] http://crrev.com/e038f1dc42693ffe6fc47c719a9051b9e0a05651/net/http/http_network_transaction_unittest.cc
[modify] http://crrev.com/e038f1dc42693ffe6fc47c719a9051b9e0a05651/net/spdy/spdy_test_util_common.cc
[modify] http://crrev.com/e038f1dc42693ffe6fc47c719a9051b9e0a05651/net/spdy/spdy_test_util_common.h
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.
Neil
Comment 18 by b...@chromium.org, Nov 30 2015
Labels: Merge-Request-48
Requesting merge of https://codereview.chromium.org/1453903002 to M48 (2564).
Comment 19 by tin...@google.com, 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 b...@chromium.org, Nov 30 2015
Status: Fixed
Project Member Comment 22 by bugdroid1@chromium.org, Dec 1 2015 
The following revision refers to this bug:
  https://chrome-internal.googlesource.com/bling/chromium.git/+/d9824e642c5db4aae9331c232421fc8ff30859c0

commit d9824e642c5db4aae9331c232421fc8ff30859c0
Author: Bence Béky <bnc@chromium.org>
Date: Mon Nov 30 14:05:45 2015
► Sign in to add a comment