Issue metadata
Sign in to add a comment
|
Can't access https://localhost server using HTTP2 (regression)
Reported by
ngy...@gmail.com,
Sep 15 2016
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.27 Safari/537.36 Example URL: Steps to reproduce the problem: If you try to access a localhost server at https://localhost that uses HTTP2, the webpage will not load if the server is using HTTP2, however it does work if it is turned off I attached a proof-of-concept node.js server inside `chromebug.zip`, to run it: 1. Add/trust the self-generated certificate `server.crt` in the OS certificate store (of course, be sure to remove it after testing) 2. Install node.js 3. Run `npm install` 4. Run `node index.js` 5. Edit `index.js` and swap line 21/22 to toggle HTTP2 on or off Video: https://www.youtube.com/watch?v=p6sBoYCWV8g What is the expected behavior? The webpage should load What went wrong? The webpage doesn't load if the localhost server is using HTTP2 Did this work before? Yes 53.0.2785.116 Chrome version: 54.0.2840.27 Channel: beta OS Version: OS X 10.11.6 Flash Version: N/A This has already regressed to 54.0.2840.27 beta
,
Sep 16 2016
When you say "this has already regressed", are you saying it used to work, and now doesn't? The net-internals log suggests that the server is sending a goaway frame after the request is made. There's nothing immediately standing out as a Chrome bug.
,
Sep 16 2016
Yeah, I noticed when my Chrome 55 dev started refusing to connect to https://localhost and thought this is another Chrome dev bug, so I retreated to Chrome 54 beta and it worked again, but even that started regressing. Chrome 53 stable still works fine as shown on my video. It's possible it could be a bug on the https://www.npmjs.com/package/spdy package instead, so I'm not 100% sure whether this is a buggy node package or newer Chrome versions got stricter with validation or whatnot.
,
Sep 16 2016
@rsleevi: Hey, would you mind replying to comment #3 ?
,
Sep 16 2016
Did you happen to note which version of M54 beta that this regressed? And Chrome Stable is still working against the same server? If so could you attach a net-internals log from a successful request on Stable?
,
Sep 16 2016
I ran a bisect: You are probably looking for a change made after 416281 (known good), but no later than 416287 (first known bad). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/c1d8aaf9fae713d96348e869877aa9c00970a71b..813945b2126b168e154d0f54c70bae7e77f05add Attached is a net-internals log from Chrome 53.0.2785.116 stable
,
Sep 16 2016
Thanks for the bug report. I can reproduce on tip of the tree, and am working on verifying your bisect results.
,
Sep 16 2016
Okay, it might be just be a bug in the `spdy` npm package, I finally tried a different web server (caddyserver.com) with this Caddyfile config: `` localhost:443 tls ../chromebug/server.crt ../chromebug/server.key `` and it does work properly with HTTP2, so it's not really a localhost issue.
,
Sep 16 2016
Yeah, it's been reported: https://github.com/indutny/spdy-transport/issues/29 and this should be marked as duplicate of https://bugs.chromium.org/p/chromium/issues/detail?id=644031 , sorry for the trouble!
,
Sep 16 2016
I confirm that the regression happened with https://crrev.com/2300683002. It seems like the node.js HTTP/2 server is not spec compliant: it fails on a valid SETTINGS frame. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by j...@externl.com
, Sep 15 2016