Hi!

It would be nice if the Server Push implementation would support Cache-Digest. It will reduce both latency and bandwidth.

PerfPlanet.com TL;DR Without Cache Digests there is no clear-cut performance win for HTTP/2 Server Push over HTTP/1 Asset Bundling. However, a Bloom filter based technique, called Cache Digests, makes Server Push more efficient than Asset Bundling in both latency and bandwidth.

https://calendar.perfplanet.com/2016/cache-digests-http2-server-push/
http://httpwg.org/http-extensions/cache-digest.html
https://jakearchibald.com/2017/h2-push-tougher-than-i-thought/

HEADERS frame is encoded incorrectly sometimes. It looks like some of the headers content is messed up. I can give a hex dump of the HEADERS frame.

Under the case ,how to write? thanks very much

:authority:xxx.XXX.com
:method:POST
:path:/api/web/v1/orders
:scheme:https
accept:application/json, text/plain, /
accept-encoding:gzip, deflate, br
accept-language:zh-CN,zh;q=0.8
content-length:71
content-type:application/json;charset=UTF-8
cookie:__zlcmid=nShV2s2YoK74QV; gpm-caveat=y; prd-token="ddd-n4Q=="; u=aaa; _gat=1; _ga=GA1.2.sss.eee; _gid=GA1.2.sss.eee
origin:https://xxx.XXX.com
referer:https://xxx.XXX.com/ex/gpm/xxx
token:ddd-n4Q==
user-agent:Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 SE 2.X MetaSr 1.0

Client doesn't seem to adhere to received SETTINGS_MAX_CONCURRENT_STREAMS.

It is observed that when server sends 100 for this setting, client sends more than 100 concurrent streams on the same connection.

It looks like you need to reactivate Travis CI for the repo after the rename: https://travis-ci.org/kaazing/http2.js

and corresponding Content-Encoding: gzip in the response.

Original Source and Fork intent

This NodeJS http2.js module version is a fork of node-http2 hosted on Github originally made by Gábor Molnár and available here: https://github.com/molnarg/node-http2

This fork of node-http2 module named http2.js starts at version 4.0.0 in case previous the repository decides to pick up work again on version 3.x.x.

We are aware that node 8.4.0 now has experimental http2 support via --expose-http2, and we will continue to support the full JavaScript implementation of http2.js at our discretion until HTTP/2 is more fully supported in a broad range of client platforms.

Changes:

4.0.1 (2017-10-01)

• Bugfixes from pull requests
  • Fails to load in IE11 due to timers.setImmediate call
  • Fix Node 5+ support #4 bug
  • update object-keys module for Object.keys shim

4.0.0 (2017-08-23)

• Rename package from 'http2' to 'http2.js'.
• Fork from abandoned https://github.com/molnarg/node-http2 to https://github.com/kaazing/http2.js and change version to '4.0.0' to avoid confusion.
• Bugfixes from pull requests
  • Clean up ended streams to free leaked memory (molnarg/node-http2#200)
  • Memory leak fix (by argon) and another 'upstream is not defined' check (molnarg/node-http2#222)
  • Allow frames to send after the arrival of the RST_STREAM. (molnarg/node-http2#210)
  • GOAWAY deserialization fix (molnarg/node-http2#235)
  • Update Mocha link (molnarg/node-http2#229)
  • Remove invalid assert (molnarg/node-http2#236)
  • Typo: finshed (molnarg/node-http2#199)
  • JSHINT all source (dpwspoon/node-http2#4)
  • Changed API to be fully pluggable for any transport or server (dpwspoon/node-http2#2)

Considering

• https://github.com/molnarg/node-http2/pull/225/files, molnarg/node-http2#224
• molnarg/node-http2#185
• molnarg/node-http2#224

Netflix has discovered several resource exhaustion vectors affecting a variety of third-party HTTP/2 implementations. These attack vectors can be used to launch DoS attacks against servers that support HTTP/2 communication.

More information here:

• https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-002.md

I think it'd would be valuable to check if this implementation is affected by this vulnerabilities.

Currently build fail with node5+.

See travis failures:

• https://travis-ci.org/kaazing/node-http2/jobs/267737043
• https://travis-ci.org/kaazing/node-http2/jobs/267737047

Hi !
we have an issue with a post request to the avs cloud.
When we post the the first request with an outdated token we receive an 403 without error what is ok.

But when we send shortly after this a next request with the same outdated token we receive a 403 AND an unhandled error.
Sometimes also fails the first invalid request.
But the point is the unhandled error which crash our application.

// without error
WARN: [Http2Wrapper] sendMessage::start

DEBUG: [Http2Wrapper] sendMessage::R-1::REQUEST:: [ 'finish', 'response', 'error', 'socket' ]
DEBUG: [Http2Wrapper] sendMessage::R-1::REQUEST socket event
DEBUG: [Http2Wrapper] sendMessage::R-1::REQUEST finish event::resolve
DEBUG: [Http2Wrapper] sendMessage::R-1::REQUEST response event:: [ 'end', 'prefinish', 'unpipe', 'drain', 'error', 'close', 'finish' ]
DEBUG: [Http2Wrapper] sendMessage::R-1::REQUEST response event::statusCode:403

DEBUG: [Http2Wrapper] sendMessage::R-1::RESPONSE data event:: chunk Unable to authenticate the request. Please provide a valid authorization token.
DEBUG: [Http2Wrapper] sendMessage::R-1::RESPONSE prefinish event
DEBUG: [Http2Wrapper] sendMessage::R-1::RESPONSE unpipe event
DEBUG: [Http2Wrapper] sendMessage::R-1::RESPONSE finish event
DEBUG: [Http2Wrapper] sendMessage::R-1::RESPONSE end event: statusCode:403

WARN: [Http2Wrapper] sendMessage::end with result { statusCode: 403 }

// SAME code with error
WARN: [Http2Wrapper] sendMessage::start

DEBUG: [Http2Wrapper] sendMessage::R-1::REQUEST:: [ 'finish', 'response', 'error', 'socket' ]
DEBUG: [Http2Wrapper] sendMessage::R-1::REQUEST socket event
DEBUG: [Http2Wrapper] sendMessage::R-1::REQUEST finish event::resolve
DEBUG: [Http2Wrapper] sendMessage::R-1::REQUEST response event:: [ 'end', 'prefinish', 'unpipe', 'drain', 'error', 'close', 'finish' ]
DEBUG: [Http2Wrapper] sendMessage::R-1::REQUEST response event::statusCode:403

DEBUG: [Http2Wrapper] sendMessage::R-1::RESPONSE data event:: chunk Unable to authenticate the request. Please provide a valid authorization token.
DEBUG: [Http2Wrapper] sendMessage::R-1::RESPONSE prefinish event
DEBUG: [Http2Wrapper] sendMessage::R-1::RESPONSE unpipe event
DEBUG: [Http2Wrapper] sendMessage::R-1::RESPONSE finish event
DEBUG: [Http2Wrapper] sendMessage::R-1::RESPONSE end event: statusCode:403

WARN: [Http2Wrapper] sendMessage::end with result { statusCode: 403 }
Error: stream.push() after EOF
at readableAddChunk (_stream_readable.js:240:30)
at Connection.Readable.push (_stream_readable.js:208:10)
at Connection._parentPush (D:\Work2018\vw.devel\iav.mib3.vw.alexa\addons\webapps\background\node_modules\http2.js\lib\protocol\flow.js:245:32)
at Connection._push (D:\Work2018\vw.devel\iav.mib3.vw.alexa\addons\webapps\background\node_modules\http2.js\lib\protocol\flow.js:257:17)
at Connection.push (D:\Work2018\vw.devel\iav.mib3.vw.alexa\addons\webapps\background\node_modules\http2.js\lib\protocol\flow.js:288:23)
at Connection._restoreWindow (D:\Work2018\vw.devel\iav.mib3.vw.alexa\addons\webapps\background\node_modules\http2.js\lib\protocol\flow.js:117:10)
at runCallback (timers.js:810:20)
at tryOnImmediate (timers.js:768:5)
at processImmediate [as _immediateCallback] (timers.js:745:5)

The following error appears when timers.setImmediate() is called.

The line of index.js above comes from https://github.com/kaazing/http2.js/blob/master/lib/protocol/connection.js#L303