spdy-http2 / spdy-transport Goto Github PK

View Code? Open in Web Editor NEW

101.0 101.0 37.0 397 KB

SPDY v2, v3, v3.1 and HTTP2 transport implementation for node.js

JavaScript 100.00%

spdy-transport's People

Contributors

Stargazers

Watchers

spdy-transport's Issues

Support "Content-Encoding" gzip, deflate for SPDY

SPDY requires support of these encodings, not sure if we want to have them here, though, since HTTP2 does not require them anymore.

Old version of readable-stream is causing Component Governace Alert

Hi team,

Is it possible to upgrade the dependency 'readable-stream' to the latest version? The old version is using 'string_decoder' which has a security issue. The latest version of readble-stream has removed string_decoder from its dependency list. Thanks.

Is there a simple way to disable frame chunking?

AssertionError [ERR_ASSERTION]: false == true

I get the error
assert.js:60
throw new errors.AssertionError({
at PriorityNode.removeChild (node_modules\spdy-transport\lib\spdy-transport\priority.js:74:3)
at PriorityNode.remove ( node_modules\spdy-transport\lib\spdy-transport\priority.js:62:15)
at PriorityTree.add ( node_modules\spdy-transport\lib\spdy-transport\priority.js:163:23)
at Stream._initPriority ( node_modules\spdy-transport\lib\spdy-transport\stream.js:101:25)
at new Stream ( node_modules\spdy-transport\lib\spdy-transport\stream.js:76:8)
at Connection._createStream ( node_modules\spdy-transport\lib\spdy-transport\connection.js:388:16)
at Connection._handleHeaders ( node_modules\spdy-transport\lib\spdy-transport\connection.js:436:21)
at Connection._handleFrame ( node_modules\spdy-transport\lib\spdy-transport\connection.js:319:10)
at Parser. ( node_modules\spdy-transport\lib\spdy-transport\connection.js:156:10)
at emitOne (events.js:115:13)
at Parser.emit (events.js:210:7)
at addChunk ( node_modules\readable-stream\lib_stream_readable.js:283:12)
at readableAddChunk ( node_modules\readable-stream\lib_stream_readable.js:270:11)
at Parser.Readable.push ( node_modules\readable-stream\lib_stream_readable.js:237:10)
at Parser.Transform.push ( node_modules\readable-stream\lib_stream_transform.js:146:32)
at next ( node_modules\spdy-transport\lib\spdy-transport\protocol\base\parser.js:53:12)

This happens on http2 push from server

The returned stream is no longer a "duplex"

I'm using duplex-passthrough to wrap the stream returned by a .request() call, so that I can buffer writes before the stream is ready and until I updated the spdy-transport version I had installed, the abstract-stream-muxer tests were passing, now, I get an error from duplex-passthrough, saying that the stream is not a duplex stream.

error:

assert.js:86
  throw new assert.AssertionError({
        ^
AssertionError: Can only wrap duplexes
    at DuplexPassThrough.wrapStream (/Users/david/Documents/Code/ipfs/node-impl/node-spdy-stream-muxer/node_modules/duplex-passthrough/dp.js:33:1)
    at /Users/david/Documents/Code/ipfs/node-impl/node-spdy-stream-muxer/src/index.js:39:10
    at /Users/david/Documents/Code/ipfs/node-impl/node-spdy-stream-muxer/node_modules/spdy-transport/lib/spdy-transport/connection.js:570:9
    at Object.callback (/Users/david/Documents/Code/ipfs/node-impl/node-spdy-stream-muxer/node_modules/spdy-transport/lib/spdy-transport/stream.js:484:5)
    at Framer.tickSync (/Users/david/Documents/Code/ipfs/node-impl/node-spdy-stream-muxer/node_modules/spdy-transport/lib/spdy-transport/protocol/base/scheduler.js:130:12)
    at Framer.tick (/Users/david/Documents/Code/ipfs/node-impl/node-spdy-stream-muxer/node_modules/spdy-transport/lib/spdy-transport/protocol/base/scheduler.js:108:13)
    at /Users/david/Documents/Code/ipfs/node-impl/node-spdy-stream-muxer/node_modules/spdy-transport/lib/spdy-transport/protocol/base/scheduler.js:102:10
    at process._tickCallback (node.js:355:11)
npm ERR! Test failed.  See above for more details.

Anything changed on the stream returned?

(note to self: lock installs to specific hashes so I can tell which version I had installed)

HTTP/2 handling of unsupported headers

As per HTTP/2 spec some headers are forbidden:

An HTTP/2.0 request or response MUST NOT include any of the following header fields:
Connection, Host, Keep-Alive, Proxy-Connection, Transfer-Encoding, and Upgrade

Is this somehow handled in this library?

AssertionError [ERR_ASSERTION]: assert(index !== -1)

I'm using react js. I found this issue there, and they told I have to post it here.
The expression evaluated to a falsy value: assert(index !== -1)
at PriorityNode.removeChild (node_modules/spdy-transport/lib/spdy-transport/priority.js:74:3)
Please help me, I have to fix it as soon as possible.

Creating client streams

@indutny can you enlighten me on how to proper create a client stream?

Have been tried to get spdystream(go version) and spdy-transport to talk, but I believe I'm missing something on the options: https://github.com/diasdavid/spdy-cross-test/blob/master/node/client.js#L11-L13

~~As far for the go-client and node-server example, it throws a error in parser.js#L133, going to start looking into the spdy tests as you suggested here: spdy-http2/node-spdy#208 (comment)~~

UPDATE:

Just realized that it spdy-transport only supports 0.12 and above, so nvm the parser.js#L133 error.

Now I get:

events.js:85
      throw er; // Unhandled 'error' event
            ^
Error: Missing `:method` and/or `:path` header

I should be able to open a stream with an empty http header. Thoughts? Removing https://github.com/indutny/spdy-transport/blob/master/lib/spdy-transport/protocol/spdy/parser.js#L152-L155 works, but I'm getting undefined undefined {} as the frame parsed.

Handler for Expect: 100-continue header (http2)

checkContinue event is emitted by spdy-server, but response.writeContinue() raises PROTOCOL_ERROR.
Client dump:

$ curl --http2 -k https://test.local -H 'Expect: 100-continue' -v
... curl/tls/certificate related messages ...
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* TCP_NODELAY set
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7fa01a00f600)
> GET / HTTP/1.1
> Host: test.local
> User-Agent: curl/7.46.0
> Accept: */*
> Expect: 100-continue
> 
* HTTP/2 stream 1 was not closed cleanly: error_code = 8
* Closing connection 0
* TLSv1.2 (OUT), TLS alert, Client hello (1):
curl: (16) HTTP/2 stream 1 was not closed cleanly: error_code = 8

Server:

$ DEBUG='spdy:*' node server.js 
  spdy:server server init secure=0 +0ms
  spdy:server incoming socket protocol="h2" +2s
  spdy:priority add node=0 parent=-1 +1ms
  spdy:window:server id=0 side=recv setMax=1048576 +2ms
  spdy:connection:server id=0 version=4 +6ms
  spdy:framer id=0 type=SETTINGS +2ms
  spdy:scheduler queue sync +3ms [ <Buffer 00 00 12 04 00 00 00 00 00>,
  <Buffer 00 02 00 00 00 00 00 04 00 10 00 00 00 06 00 01 40 00> ]
  spdy:connection:server id=0 session window drain, update by 983041 +1ms
  spdy:framer id=0 type=WINDOW_UPDATE +0ms
  spdy:scheduler queue sync +1ms [ <Buffer 00 00 04 08 00 00 00 00 00>, <Buffer 00 0f 00 01> ]
  spdy:window:server id=0 side=recv update by=983041 [1048576/1048576] +1ms
  spdy:scheduler tick sync pending=4 +1ms [ <Buffer 00 00 12 04 00 00 00 00 00>,
  <Buffer 00 02 00 00 00 00 00 04 00 10 00 00 00 06 00 01 40 00> ]
  spdy:scheduler after tick sync pending=2 +2ms
  spdy:scheduler tick sync pending=2 +0ms [ <Buffer 00 00 04 08 00 00 00 00 00>, <Buffer 00 0f 00 01> ]
  spdy:scheduler after tick sync pending=0 +1ms
  spdy:connection:server id=0 frame +2ms { type: 'SETTINGS', settings: {} }
  spdy:framer id=0 type=SETTINGS +1ms
  spdy:scheduler queue sync +0ms [ <Buffer 00 00 00 04 01 00 00 00 00> ]
  spdy:scheduler tick sync pending=1 +1ms [ <Buffer 00 00 00 04 01 00 00 00 00> ]
  spdy:scheduler after tick sync pending=0 +0ms
  spdy:connection:server id=0 frame +4ms { type: 'HEADERS',
  id: 1,
  priority: { parent: 0, exclusive: false, weight: 16 },
  fin: true,
  writable: true,
  headers: 
   { ':method': 'GET',
     ':path': '/',
     ':scheme': 'https',
     ':authority': 'test.local',
     'user-agent': 'curl/7.46.0',
     accept: '*/*',
     expect: '100-continue' },
  path: '/' }
  spdy:priority add node=1 parent=0 +6ms
  spdy:connection:server id=0 add stream=1 +1ms
  spdy:stream:server id=1 presend=25 +6ms
  spdy:window:server id=1 side=send update by=-25 [65510/65535] +0ms
  spdy:stream:server id=1 end +4ms
  spdy:stream:server id=1 send=25 +1ms
  spdy:framer id=1 type=DATA +1ms
  spdy:window:server id=0 side=send update by=-25 [65510/65535] +0ms
  spdy:scheduler queue async priority=1 stream=1 +2ms [ <Buffer 00 00 19 00 00 00 00 00 01>,
  <Buffer 48 54 54 50 2f 31 2e 31 20 31 30 30 20 43 6f 6e 74 69 6e 75 65 0d 0a 0d 0a> ]
  spdy:scheduler tick async index=0 start=1 +1ms
  spdy:scheduler tick async pending=2 +1ms [ <Buffer 00 00 19 00 00 00 00 00 01>,
  <Buffer 48 54 54 50 2f 31 2e 31 20 31 30 30 20 43 6f 6e 74 69 6e 75 65 0d 0a 0d 0a> ]
  spdy:scheduler after tick pending=0 +1ms
  spdy:stream:server id=1 postsend=25 +1ms
  spdy:stream:server id=1 presend=314 +1ms
  spdy:window:server id=1 side=send update by=-314 [65196/65535] +1ms
  spdy:stream:server id=1 send=314 +1ms
  spdy:framer id=1 type=DATA +1ms
  spdy:window:server id=0 side=send update by=-314 [65196/65535] +0ms
  spdy:scheduler queue async priority=1 stream=1 +0ms [ <Buffer 00 01 3a 00 00 00 00 00 01>,
  <Buffer 48 54 54 50 2f 31 2e 31 20 32 30 30 20 4f 4b 0d 0a 53 65 72 76 65 72 3a 20 6e 6f 64 65 2f 76 35 2e 31 2e 31 0d 0a 43 6f 6e 6e 65 63 74 69 6f 6e 3a 20 ... > ]
  spdy:scheduler tick async index=0 start=1 +1ms
  spdy:scheduler tick async pending=2 +0ms [ <Buffer 00 01 3a 00 00 00 00 00 01>,
  <Buffer 48 54 54 50 2f 31 2e 31 20 32 30 30 20 4f 4b 0d 0a 53 65 72 76 65 72 3a 20 6e 6f 64 65 2f 76 35 2e 31 2e 31 0d 0a 43 6f 6e 6e 65 63 74 69 6f 6e 3a 20 ... > ]
  spdy:scheduler after tick pending=0 +1ms
  spdy:stream:server id=1 postsend=314 +0ms
  spdy:stream:server id=1 presend=5 +1ms
  spdy:window:server id=1 side=send update by=-5 [65191/65535] +0ms
  spdy:stream:server id=1 send=5 +1ms
  spdy:framer id=1 type=DATA +0ms
  spdy:window:server id=0 side=send update by=-5 [65191/65535] +0ms
  spdy:scheduler queue async priority=1 stream=1 +1ms [ <Buffer 00 00 05 00 00 00 00 00 01>, <Buffer 30 0d 0a 0d 0a> ]
  spdy:scheduler tick async index=0 start=1 +0ms
  spdy:scheduler tick async pending=2 +0ms [ <Buffer 00 00 05 00 00 00 00 00 01>, <Buffer 30 0d 0a 0d 0a> ]
  spdy:scheduler after tick pending=0 +1ms
  spdy:stream:server id=1 postsend=5 +0ms
  spdy:stream:server id=1 abort +2ms
  spdy:framer id=1 type=RST_STREAM +0ms
  spdy:scheduler queue sync +1ms [ <Buffer 00 00 04 03 00 00 00 00 01>, <Buffer 00 00 00 08> ]
  spdy:scheduler tick sync pending=2 +0ms [ <Buffer 00 00 04 03 00 00 00 00 01>, <Buffer 00 00 00 08> ]
  spdy:scheduler after tick sync pending=0 +1ms
  spdy:connection:server id=0 remove stream=1 +1ms
  spdy:connection:server id=0 frame +1ms { type: 'ACK_SETTINGS' }
  spdy:connection:server id=0 frame +1ms { type: 'GOAWAY',
  lastId: 0,
  code: 'PROTOCOL_ERROR',
  debug: <Buffer 44 41 54 41 3a 20 73 74 72 65 61 6d 20 6e 6f 74 20 6f 70 65 6e 65 64> }
  spdy:connection:server id=0 goaway from=0 +2ms
  spdy:connection:server id=0 _onStreamDrain +1ms

When using fallback to http/1.1 all works:

$ https://test.local -H 'Expect: 100-continue' -v
...
> GET / HTTP/1.1
> Host: test.local
> User-Agent: curl/7.46.0
> Accept: */*
> Expect: 100-continue
> 
< HTTP/1.1 100 Continue
< HTTP/1.1 200 OK
< Server: node/v5.1.1
< Connection: keep-alive
< Date: Tue, 08 Dec 2015 14:41:34 GMT
< Content-Type: text/plain
< Transfer-Encoding: chunked
< 
... data ...
* Connection #0 to host test.local left intact

Support plain (non-SSL) connections

As discussed on Twitter, this is a remaining TODO for this module.
{ plain: true, ssl: false } is documented, but doesn't seem to do anything.

Reference: https://httpwg.github.io/specs/rfc7540.html#discover-http

.on('stream') emits a second time when stream.end() is called

I'm getting a a second stream event emitted after I call stream.end() on the listener side.

Test: https://github.com/diasdavid/abstract-stream-muxer/blob/master/tests/stress-test.js#L17-L63

Run it with node-spdy-stream-muxer[1] - https://github.com/diasdavid/node-spdy-stream-muxer (npm i && npm test, it uses tap))

[1] A bit of context, node-spdy-stream-muxer is just a thin veneer on top of spdy-transport to be compatible with abstract-stream-muxer, so that we can run the same battery of tests on several stream-muxer, like we are doing in the Go land - https://github.com/jbenet/go-stream-muxer. Greatly inspired by https://github.com/maxogden/abstract-blob-store

multi streams aka push streams

I need some clarifications on the push streams API. Mainly, why is the stream object the interface to open more streams and not the client/server objects themselves?

e g

Does that mean that every 2nd or later stream is always a child to the first stream opened? Can't streams between a client and a server live in parallel?

For example, the go impl offers a interface on the Connection interface to open 1-n streams without having to create nesting

SyntaxError: Unexpected identifier

Running into this error when starting my express server:

node_modules/spdy-transport/lib/spdy-transport/priority.js:81
PriorityNode.prototype.removeChildren = function removeChildren () {
^^^^^^^^^^^^

SyntaxError: Unexpected identifier
    at createScript (vm.js:80:10)
    at Object.runInThisContext (vm.js:139:10)
    at Module._compile (module.js:607:28)
    at Object.Module._extensions..js (module.js:654:10)
    at Module.load (module.js:556:32)
    at tryModuleLoad (module.js:499:12)
    at Function.Module._load (module.js:491:3)
    at Module.require (module.js:587:17)
    at require (internal/module.js:11:18)

Not able to resolve it.

QUIC transport

Any plans to implement QUIC protocol?
http://tools.ietf.org/html/draft-tsvwg-quic-protocol-00
https://github.com/devsisters/libquic
https://github.com/romain-jacotin/quic

coverage directory contents inadvertently included with npm, please remove

spdy-transport npm includes a coverage directory that has a coverage.json file in it.
This is somehow picked up by istanbul in other unrelated projects and it wreaks havoc.
Let me know if I am missing anything, but I believe this problem exists in the latest release

`master` is not working (although all tests pass)

spdy-transport master branch is not working, although every single test passes.

It throws an error, simply by calling transport.connection.create

// simple example
var tcp = require('net')
var transport = require('spdy-transport')

tcp.createServer(function (socket) {
  var listener = transport.connection.create(socket, {
    protocol: 'spdy',
    isServer: true
  })
}).listen(8020)

#  error
» node listener.js                                                                                 
timers.js:165
    throw new TypeError('msecs must be a number');
          ^
TypeError: msecs must be a number
    at Object.exports.enroll (timers.js:165:11)
    at Socket.setTimeout (net.js:337:12)
    at Connection.init [as _init] (/Users/david/Documents/Code/ipfs/mss-spdy-example/node_modules/spdy-transport/lib/spdy-transport/connection.js:168:17)
    at new Connection (/Users/david/Documents/Code/ipfs/mss-spdy-example/node_modules/spdy-transport/lib/spdy-transport/connection.js:126:8)
    at Function.create (/Users/david/Documents/Code/ipfs/mss-spdy-example/node_modules/spdy-transport/lib/spdy-transport/connection.js:132:10)
    at Server.<anonymous> (/Users/david/Documents/Code/ipfs/mss-spdy-example/src/listener-2.js:7:39)
    at Server.emit (events.js:107:17)
    at TCP.onconnection (net.js:1330:8)

Code coverage?

Considering how big is the source of this library, code coverage may be a good way to measure the quality of the code.

A dialer connection/endpoint can dial streams to a dialer connection/endpoint, it only throws (RST_STREAM) when the second dialer tries to dial back

I found (by my mistake in putting the wrong bool on 'isServer') that a spdy-transport client can dial a stream through a socket that has a client in the other side without throwing any errors, however, if the dialer in the other side (which should be in fact a listener/server), tries to dial back a stream, we receive a RST_STREAM. Probably because it tries to use the same STREAM_ID and that is when it understand that both endpoints are dialers?

AssertionError [ERR_ASSERTION]: false == true

I've been periodically seeing this error in my app:

assert.js:42
  throw new errors.AssertionError({
  ^

AssertionError [ERR_ASSERTION]: false == true
    at PriorityNode.removeChild (~/project/node_modules/spdy-transport/lib/spdy-transport/priority.js:74:3)
    at PriorityNode.remove (~/project/node_modules/spdy-transport/lib/spdy-transport/priority.js:62:15)
    at PriorityTree.add (~/project/node_modules/spdy-transport/lib/spdy-transport/priority.js:163:23)
    at Stream._initPriority (~/project/node_modules/spdy-transport/lib/spdy-transport/stream.js:101:25)
    at new Stream (~/project/node_modules/spdy-transport/lib/spdy-transport/stream.js:76:8)
    at Connection._createStream (~/project/node_modules/spdy-transport/lib/spdy-transport/connection.js:388:16)
    at Connection._handleHeaders (~/project/node_modules/spdy-transport/lib/spdy-transport/connection.js:436:21)
    at Connection._handleFrame (~/project/node_modules/spdy-transport/lib/spdy-transport/connection.js:319:10)
    at Parser.<anonymous> (~/project/node_modules/spdy-transport/lib/spdy-transport/connection.js:156:10)
    at emitOne (events.js:116:13)
    at Parser.emit (events.js:211:7)
    at addChunk (~/project/node_modules/readable-stream/lib/_stream_readable.js:291:12)
    at readableAddChunk (~/project/node_modules/readable-stream/lib/_stream_readable.js:278:11)
    at Parser.Readable.push (~/project/node_modules/readable-stream/lib/_stream_readable.js:245:10)
    at Parser.Transform.push (~/project/node_modules/readable-stream/lib/_stream_transform.js:148:32)
    at next (~/project/node_modules/spdy-transport/lib/spdy-transport/protocol/base/parser.js:53:12)
    at ~/project/node_modules/spdy-transport/lib/spdy-transport/protocol/http2/parser.js:72:5
    at ~/project/node_modules/spdy-transport/lib/spdy-transport/protocol/http2/parser.js:293:5
    at done (~/project/node_modules/spdy-transport/lib/spdy-transport/utils.js:84:5)
    at next (~/project/node_modules/spdy-transport/lib/spdy-transport/utils.js:102:5)
    at afterWrite (~/project/node_modules/readable-stream/lib/_stream_writable.js:491:3)
    at _combinedTickCallback (internal/process/next_tick.js:144:20)
    at process._tickCallback (internal/process/next_tick.js:180:9)

I'm sorry I don't have an actual test-case yet. This seems to happen when I open a number of tabs to different pages, and eventually I get a crash.

Error: Cannot find module 'obuf'

When I run npm start in my project on my new developer PC I get this error:

PS C:\Users\alexa\ae2> npm start

> [email protected] start C:\Users\alexa\ae2
> node scripts/start.js

module.js:487
    throw err;
    ^

Error: Cannot find module 'obuf'
    at Function.Module._resolveFilename (module.js:485:15)
    at Function.Module._load (module.js:437:25)
    at Module.require (module.js:513:17)
    at require (internal/module.js:11:18)
    at Object.<anonymous> (C:\Users\alexa\ae2\node_modules\spdy-transport\lib\spdy-transport\protocol\base\parser.js:7:20)
    at Module._compile (module.js:569:30)
    at Object.Module._extensions..js (module.js:580:10)
    at Module.load (module.js:503:32)
    at tryModuleLoad (module.js:466:12)
    at Function.Module._load (module.js:458:3)
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] start: `node scripts/start.js`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\alexa\AppData\Roaming\npm-cache\_logs\2017-06-19T12_47_31_366Z-debug.log
PS C:\Users\alexa\ae2>

It seems that spdy-transport causes this?

The PC runs:

Windows 10
node v8.1.2

This error does not occur on my old Windows 10 PC and my macOS running sierra.

Faulty buffer write operations

Right now the framer has multiple buffer.writeUInt32BE calls. In case priority.exclusive is truthy it can pass in a negative value because 0x80000000 | undefined === -(2 ** 31).

This currently works because the buffer write operation will overflow and safe that value. That will not be possible in future versions anymore.

Right now the test should generate priority request frame will result in such a case. I tried to fix it but I am not sure what the right solution should be. Ping @indutny

Refs: nodejs/node#18395

Scheduler does not obey Stream.push api

Currently when the Scheduler ticks it will run through all chunks for all scheduled items and push the chunks onto the stream. The resulting Boolean from push is not checked for every chunk, which can result in an error if pushes become disallowed during the tick.

The problem lines are
https://github.com/spdy-http2/spdy-transport/blob/v2.1.1/lib/spdy-transport/protocol/base/scheduler.js#L124
and
https://github.com/spdy-http2/spdy-transport/blob/v2.1.1/lib/spdy-transport/protocol/base/scheduler.js#L164

Error: Got RST: CANCEL

Hi,

I was connected with Chrome and don't remember doing anything funky, but all of the sudden I noticed the following printed in my Node terminal:

Error: Got RST: CANCEL
    at Stream._handleRST (/myproject/node_modules/spdy-transport/lib/spdy-transport/stream.js:265:22)
    at Stream._handleFrame (/myproject/node_modules/spdy-transport/lib/spdy-transport/stream.js:118:10)
    at Connection._handleFrame (/myproject/node_modules/spdy-transport/lib/spdy-transport/connection.js:299:12)
    at Parser.<anonymous> (/myproject/node_modules/spdy-transport/lib/spdy-transport/connection.js:149:10)
    at emitOne (events.js:77:13)
    at Parser.emit (events.js:169:7)
    at readableAddChunk (/myproject/node_modules/spdy-transport/node_modules/readable-stream/lib/_stream_readable.js:199:16)
    at Parser.Readable.push (/myproject/node_modules/spdy-transport/node_modules/readable-stream/lib/_stream_readable.js:163:10)
    at Parser.Transform.push (/myproject/node_modules/spdy-transport/node_modules/readable-stream/lib/_stream_transform.js:133:32)
    at next (/myproject/node_modules/spdy-transport/lib/spdy-transport/protocol/base/parser.js:52:12)

I didn't notice anything strange in the browser.
I wonder if this is an issue in Chrome or in spdy-transport..?

Versions:

Chrome 46.0.2490.80 (64-bit)
spdy: 2.1.0
spdy-transport: 1.2.1
Node.js: 5.1.0

Best way to graciously close a 'muxed socket' with `spdy-transport`

@indutny what would the best practice you recommend graciously close a muxed socket, without having it blow up in the other side because of the socket hanging up? As in:

Uncaught Error: socket hang up
  at Socket.onclose (node_modules/spdy-transport/lib/spdy-transport/connection.js:186:15)
  at TCP._onclose (net.js:477:12)

Is listening on the spdy dialer/listener object for 'error' the best option?

Thank you :)

h2spec

Looks like there are many errors when running h2spec against spdy-transport.

===============================================================================
Failed tests
===============================================================================

  4.3. Header Compression and Decompression
    × Encodes Dynamic Table Size Update (RFC 7541, 6.3) after common header fields
      - The endpoint MUST terminate the connection with a connection error of type COMPRESSION_ERROR.
        Expected: GOAWAY frame (ErrorCode: COMPRESSION_ERROR)
                  Connection close
          Actual: DATA frame (Length: 0, Flags: 1)

  5.1. Stream States
    × idle: Sends a DATA frame
      - The endpoint MUST treat this as a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
        Expected: GOAWAY frame (ErrorCode: PROTOCOL_ERROR)
                  Connection close
          Actual: RST_STREAM frame (Length: 4, Flags: 0, ErrorCode: STREAM_CLOSED)
    × idle: Sends a RST_STREAM frame
      - The endpoint MUST treat this as a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
        Expected: GOAWAY frame (ErrorCode: PROTOCOL_ERROR)
                  Connection close
          Actual: Test timeout
    × idle: Sends a WINDOW_UPDATE frame
      - The endpoint MUST treat this as a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
        Expected: GOAWAY frame (ErrorCode: PROTOCOL_ERROR)
                  Connection close
          Actual: RST_STREAM frame (Length: 4, Flags: 0, ErrorCode: STREAM_CLOSED)
    × half closed (remote): Sends a HEADERS frame
      - The endpoint MUST respond with a stream error (Section 5.4.2) of type STREAM_CLOSED.
        Expected: GOAWAY frame (ErrorCode: STREAM_CLOSED)
                  RST_STREAM frame (ErrorCode: STREAM_CLOSED)
                  Connection close
          Actual: DATA frame (Length: 0, Flags: 1)

    5.1.1. Stream Identifiers
      × Sends even-numbered stream identifier
        - The endpoint MUST respond with a connection error of type PROTOCOL_ERROR.
          Expected: GOAWAY frame (ErrorCode: PROTOCOL_ERROR)
                    Connection close
            Actual: RST_STREAM frame (Length: 4, Flags: 0, ErrorCode: PROTOCOL_ERROR)

  5.4. Error Handling
    5.4.1. Connection Error Handling
      × Receives a GOAWAY frame
        - After sending the GOAWAY frame, the endpoint MUST close the TCP connection.
          Expected: Connection close
            Actual: Error: Connection closed, but did not receive a GOAWAY Frame.

  5.5. Extending HTTP/2
    × Sends an unknown extension frame in the middle of a header block
      - The endpoint MUST treat as a connection error of type PROTOCOL_ERROR.
        Expected: GOAWAY frame (ErrorCode: PROTOCOL_ERROR)
                  Connection close
          Actual: Test timeout

  6.1. DATA
    × Sends a DATA frame with 0x0 stream identifier
      - The endpoint MUST respond with a connection error of type PROTOCOL_ERROR.
        Expected: GOAWAY frame (ErrorCode: PROTOCOL_ERROR)
                  Connection close
          Actual: Error: connection error: PROTOCOL_ERROR

  6.2. HEADERS
    × Sends a HEADERS frame followed by any frame other than CONTINUATION
      - The endpoint MUST treat the receipt of any other type of frame as a connection error of type PROTOCOL_ERROR.
        Expected: GOAWAY frame (ErrorCode: PROTOCOL_ERROR)
                  Connection close
          Actual: RST_STREAM frame (Length: 4, Flags: 0, ErrorCode: STREAM_CLOSED)

  6.4. RST_STREAM
    × Sends a RST_STREAM frame on a idle stream
      - The endpoint MUST respond with a connection error of type PROTOCOL_ERROR.
        Expected: GOAWAY frame (ErrorCode: PROTOCOL_ERROR)
                  Connection close
          Actual: Test timeout

  6.5. SETTINGS
    6.5.2. Defined SETTINGS Parameters
      × SETTINGS_ENABLE_PUSH (0x2): Sends the value other than 0 or 1
        - The endpoint MUST respond with a connection error of type PROTOCOL_ERROR.
          Expected: GOAWAY frame (ErrorCode: PROTOCOL_ERROR)
                    Connection close
            Actual: SETTINGS frame (Length: 0, Flags: 1)
      × SETTINGS_INITIAL_WINDOW_SIZE (0x4): Sends the value above the maximum flow control window size
        - The endpoint MUST respond with a connection error of type FLOW_CONTROL_ERROR.
          Expected: GOAWAY frame (ErrorCode: FLOW_CONTROL_ERROR)
                    Connection close
            Actual: SETTINGS frame (Length: 0, Flags: 1)
      × SETTINGS_MAX_FRAME_SIZE (0x5): Sends the value below the initial value
        - The endpoint MUST respond with a connection error of type PROTOCOL_ERROR.
          Expected: GOAWAY frame (ErrorCode: PROTOCOL_ERROR)
                    Connection close
            Actual: SETTINGS frame (Length: 0, Flags: 1)
      × SETTINGS_MAX_FRAME_SIZE (0x5): Sends the value above the maximum allowed frame size
        - The endpoint MUST respond with a connection error of type PROTOCOL_ERROR.
          Expected: GOAWAY frame (ErrorCode: PROTOCOL_ERROR)
                    Connection close
            Actual: SETTINGS frame (Length: 0, Flags: 1)

  6.9. WINDOW_UPDATE
    × Sends a WINDOW_UPDATE frame with an flow control window increment of 0
      - The endpoint MUST respond with a connection error of type PROTOCOL_ERROR.
        Expected: GOAWAY frame (ErrorCode: PROTOCOL_ERROR)
                  Connection close
          Actual: Test timeout
    × Sends a WINDOW_UPDATE frame with an flow control window increment of 0 on a stream
      - The endpoint MUST respond with a stream error of type PROTOCOL_ERROR.
        Expected: GOAWAY frame (ErrorCode: PROTOCOL_ERROR)
                  RST_STREAM frame (ErrorCode: PROTOCOL_ERROR)
                  Connection close
          Actual: DATA frame (Length: 0, Flags: 1)

    6.9.1. The Flow Control Window
      × Sends multiple WINDOW_UPDATE frames on a connection increasing the flow control window to above 2^31-1
        - The endpoint MUST sends a GOAWAY frame with a FLOW_CONTROL_ERROR code.
          Expected: GOAWAY frame (ErrorCode: FLOW_CONTROL_ERROR)
            Actual: Test timeout
      × Sends multiple WINDOW_UPDATE frames on a stream increasing the flow control window to above 2^31-1
        - The endpoint MUST sends a RST_STREAM with the error code of FLOW_CONTROL_ERROR code.
          Expected: RST_STREAM frame (ErrorCode: FLOW_CONTROL_ERROR)
            Actual: DATA frame (Length: 0, Flags: 1)

    6.9.2. Initial Flow Control Window Size
      × Sends a SETTINGS_INITIAL_WINDOW_SIZE settings with an exceeded maximum window size value
        - The endpoint MUST respond with a connection error of type FLOW_CONTROL_ERROR.
          Expected: GOAWAY frame (ErrorCode: FLOW_CONTROL_ERROR)
                    Connection close
            Actual: SETTINGS frame (Length: 0, Flags: 1)

  6.10. CONTINUATION
    × Sends a CONTINUATION frame followed by any frame other than CONTINUATION
      - The endpoint MUST treat as a connection error of type PROTOCOL_ERROR.
        Expected: GOAWAY frame (ErrorCode: PROTOCOL_ERROR)
                  Connection close
          Actual: RST_STREAM frame (Length: 4, Flags: 0, ErrorCode: STREAM_CLOSED)

  8.1. HTTP Request/Response Exchange
    × Sends a second HEADERS frame without the END_STREAM flag
      - The endpoint MUST respond with a stream error of type PROTOCOL_ERROR.
        Expected: GOAWAY frame (ErrorCode: PROTOCOL_ERROR)
                  RST_STREAM frame (ErrorCode: PROTOCOL_ERROR)
                  Connection close
          Actual: DATA frame (Length: 0, Flags: 1)

    8.1.2. HTTP Header Fields
      × Sends a HEADERS frame that contains the header field name in uppercase letters
        - The endpoint MUST respond with a stream error of type PROTOCOL_ERROR.
          Expected: GOAWAY frame (ErrorCode: PROTOCOL_ERROR)
                    RST_STREAM frame (ErrorCode: PROTOCOL_ERROR)
                    Connection close
            Actual: DATA frame (Length: 0, Flags: 1)

      8.1.2.1. Pseudo-Header Fields
        × Sends a HEADERS frame that contains the pseudo-header field defined for response
          - The endpoint MUST respond with a stream error of type PROTOCOL_ERROR.
            Expected: GOAWAY frame (ErrorCode: PROTOCOL_ERROR)
                      RST_STREAM frame (ErrorCode: PROTOCOL_ERROR)
                      Connection close
              Actual: DATA frame (Length: 0, Flags: 1)
        × Sends a HEADERS frame that contains the invalid pseudo-header field
          - The endpoint MUST respond with a stream error of type PROTOCOL_ERROR.
            Expected: GOAWAY frame (ErrorCode: PROTOCOL_ERROR)
                      RST_STREAM frame (ErrorCode: PROTOCOL_ERROR)
                      Connection close
              Actual: DATA frame (Length: 0, Flags: 1)
        × Sends a HEADERS frame that contains a pseudo-header field that appears in a header block after a regular header field
          - The endpoint MUST respond with a stream error of type PROTOCOL_ERROR.
            Expected: GOAWAY frame (ErrorCode: PROTOCOL_ERROR)
                      RST_STREAM frame (ErrorCode: PROTOCOL_ERROR)
                      Connection close
              Actual: DATA frame (Length: 0, Flags: 1)

      8.1.2.2. Connection-Specific Header Fields
        × Sends a HEADERS frame that contains the connection-specific header field
          - The endpoint MUST respond with a stream error of type PROTOCOL_ERROR.
            Expected: GOAWAY frame (ErrorCode: PROTOCOL_ERROR)
                      RST_STREAM frame (ErrorCode: PROTOCOL_ERROR)
                      Connection close
              Actual: DATA frame (Length: 0, Flags: 1)
        × Sends a HEADERS frame that contains the TE header field that contain any value other than "trailers"
          - The endpoint MUST respond with a stream error of type PROTOCOL_ERROR.
            Expected: GOAWAY frame (ErrorCode: PROTOCOL_ERROR)
                      RST_STREAM frame (ErrorCode: PROTOCOL_ERROR)
                      Connection close
              Actual: DATA frame (Length: 0, Flags: 1)

      8.1.2.3. Request Pseudo-Header Fields
        × Sends a HEADERS frame that omits mandatory pseudo-header fields
          - The endpoint MUST respond with a stream error of type PROTOCOL_ERROR.
            Expected: GOAWAY frame (ErrorCode: PROTOCOL_ERROR)
                      RST_STREAM frame (ErrorCode: PROTOCOL_ERROR)
                      Connection close
              Actual: DATA frame (Length: 0, Flags: 1)
        × Sends a HEADERS frame containing more than one pseudo-header fields with the same name
          - The endpoint MUST respond with a stream error of type PROTOCOL_ERROR.
            Expected: GOAWAY frame (ErrorCode: PROTOCOL_ERROR)
                      RST_STREAM frame (ErrorCode: PROTOCOL_ERROR)
                      Connection close
              Actual: DATA frame (Length: 0, Flags: 1)

      8.1.2.6. Malformed Requests and Responses
        × Sends a HEADERS frame that contains the "content-length" header field which does not equal the sum of the DATA frame payload lengths
          - The endpoint MUST respond with a stream error of type PROTOCOL_ERROR.
            Expected: GOAWAY frame (ErrorCode: PROTOCOL_ERROR)
                      RST_STREAM frame (ErrorCode: PROTOCOL_ERROR)
                      Connection close
              Actual: DATA frame (Length: 0, Flags: 1)
        × Sends a HEADERS frame that contains the "content-length" header field which does not equal the sum of the multiple DATA frame payload lengths
          - The endpoint MUST respond with a stream error of type PROTOCOL_ERROR.
            Expected: GOAWAY frame (ErrorCode: PROTOCOL_ERROR)
                      RST_STREAM frame (ErrorCode: PROTOCOL_ERROR)
                      Connection close
              Actual: DATA frame (Length: 0, Flags: 1)

  8.2. Server Push
    × Sends a PUSH_PROMISE frame
      - The endpoint MUST treat the receipt of a PUSH_PROMISE frame as a connection error of type PROTOCOL_ERROR.
        Expected: GOAWAY frame (ErrorCode: PROTOCOL_ERROR)
                  Connection close
          Actual: RST_STREAM frame (Length: 4, Flags: 0, ErrorCode: STREAM_CLOSED)

stream.destroy()

@mafintosh just asked me in IRC about a way to "blow up" a spdy stream. Context:

23:59 @mafintosh daviddias: we need a way to blow up the stream
23:59 @mafintosh in case of errors etc
23:59 @mafintosh daviddias: its usually implemented with stream.destroy() in node

I couldn't find any method on streams.js for destroy, nor in tests, is there something implemented I'm missing?

SPDY compression pool

@indutny does creating a spdy compression pool require an extra option? Other than:
https://github.com/diasdavid/spdy-transport/blob/spdy-parser-tests/test/spdy/parser-test.js#L10-L13

Getting this err:

  1) SPDY Parser "before each" hook:
     TypeError: Cannot read property 'length' of undefined
      at Pool.get (lib/spdy-transport/protocol/spdy/zlib-pool.js:43:25)
      at Context.<anonymous> (test/spdy/parser-test.js:12:21)

Cannot find module 'hpack.js'

Hey there, my team just started a new project using the latest version of webpack-dev-server (2.7.1), and when starting up the server we are all consistently seeing the following error.

Error: Cannot find module 'hpack.js'
    at Function.Module._resolveFilename (module.js:440:15)
    at Function.Module._load (module.js:388:25)
    at Module.require (module.js:468:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (/Users/a6001382/analytics/analytics-q/node_modules/spdy-transport/lib/spdy-transport/protocol/http2/hpack-pool.js:5:13)

The issue is still persisting even after attempting to install hpack.js as a globally available dependency. Is there a way to resolve this?

Client setting SETTINGS_HEADER_TABLE_SIZE causes connection reset in Chrome 55.0.2853.0 dev

Wasn't sure whether to open this here on in hpack.js, as I don't know enough about the topic.

See the discussion in the Chromium tracker.

The offending code seems to be here:

And the spec says:

SETTINGS_HEADER_TABLE_SIZE (0x1): Allows the sender to inform the remote endpoint of the maximum size of the header compression table used to decode header blocks, in octets. The encoder can select any size equal to or less than this value by using signaling specific to the header compression format inside a header block (see [COMPRESSION]). The initial value is 4,096 octets.

The fact that maxSize also sets maxProtocolSize seems to break things.

Firefox H2 connection reset

Hi, I'm having problems with spdy since today.

I'm using spdy v3.0.0 package. I was not able to isolate the problem in short time, but only difference I can see is the upgrade of the spdy-transport (it got automatic update from 2.0.4 to 2.0.5 during install of spdy).

I'm sorry I don't have better information at this point, I'll try to provide more info in next couple of days. I can confirm that Chrome, Safari and IE are working ok.

Firefox error:

Secure Connection Failed

The connection to the server was reset while the page was loading.

    The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
    Please contact the website owners to inform them of this problem.

H2 Protocol on iOS device

Hi there,

Hope you well. I just take a tour on issues to match my problem and maybe the #33 and #22 are linked.
I am unable to connect to my app using H2 protocol. The connection stales and dies after couple of minutes.
When i remove H2 from protocols list then my app works.

If you have any idea.

Michael

Write test for 1b74d84

See: 1b74d84

Server but no client?

I am working on a way to run traditionally server-side stacks (think 'express') in the browser and need a way to serve requests over WebRTC. It's surprisingly hard to find a generic HTTP parser/generator that operates on strings or streams instead of Node TCP sockets. And HTTP2 would be even better because of its support for multiplexing concurrent requests on the same stream, in this case the WebRTC data channel. However, I haven't found an HTTP2 client library that could sit at the other end of the stream and talk to spdy-transport, which AFAICT is just the server half of the conversation. Have you thought about that or worked on a client that I just haven't found?

Opening a stream in both sides makes one of them send a RST_STREAM and throw

Wrote one more test on abstract-stream-muxer to identify a bug I was getting in ipfs-swarm, it seems that in 1.0.0-rc7, when we attempt to open a stream in both sides, one of them throws

test: https://github.com/diasdavid/abstract-stream-muxer/blob/master/tests/base-test.js#L51-L81
To run it using spdy-transport, git clone this repo https://github.com/diasdavid/node-spdy-stream-muxer, install deps and npm test.

I'm using 1.0.0-rc7 because of this issue: #9

Add .npmignore.

Ignoring test would save something like 100KB from the final package.

Separate license file?

The license is embedded into the README, can we have a separate license file?

be a duplex stream

Hi. Great work on getting the spdy protocol working 🎉

Instead of having the transport.connection.create accept a stream it would be nice if it instead just returned a duplex stream that you could pipe your transport to/from.

var spdy = transport.connection.create()
var socket = net.connect(...)

var req = spdy.request(...)
spdy.on('stream', function (stream) {
  ...
})

socket.pipe(spdy).pipe(socket)

This makes it easier compose stream pipelines with spdy. For example using stdin/stdout

process.stdin.pipe(spdy).pipe(process.stdout)

Or using an encrypted stream

transport.pipe(decryptor).pipe(spdy).pipe(encryptor).pipe(transport)

If this is something you'd be interested in adding I'd be happy to help out with a PR

test broken on master for all versions of node

  1 failing

  1) Framer http2 (v4) HEADERS should generate priority request frame:
     Uncaught TypeError: "value" argument is out of bounds
      at checkInt (buffer.js:1180:11)
      at Buffer.writeUInt32BE (buffer.js:1273:5)
      at WBuf.writeUInt32BE (node_modules/wbuf/index.js:281:15)
      at lib/spdy-transport/protocol/http2/framer.js:257:11
      at lib/spdy-transport/protocol/http2/framer.js:117:30
      at Framer._frame (lib/spdy-transport/protocol/http2/framer.js:41:3)
      at Framer.<anonymous> (lib/spdy-transport/protocol/http2/framer.js:110:10)
      at Array.forEach (<anonymous>)
      at Framer._continuationFrame (lib/spdy-transport/protocol/http2/framer.js:99:10)
      at lib/spdy-transport/protocol/http2/framer.js:246:10
      at done (lib/spdy-transport/utils.js:84:5)
      at next (lib/spdy-transport/utils.js:102:5)
      at afterWrite (node_modules/readable-stream/lib/_stream_writable.js:481:3)
      at _combinedTickCallback (internal/process/next_tick.js:144:20)
      at process._tickCallback (internal/process/next_tick.js:180:9)

Defer push response headers in http2

Thanks for giving us such an awesome node module!

In HTTP/2, the response headers and status code for a pushed resource shouldn't have to be sent immediately.
It would be very useful if we had the option to defer sending the response headers and status code, giving us the chance to fetch them from another server along with the response body.

The relevant code seems to be in http2/framer.js, in pushFrame(), in the callback to _checkPush. The status code and response headers are compressed and sent immediately.

spdy-http2 / spdy-transport Goto Github PK

spdy-transport's People

Contributors

Stargazers

Watchers

Forkers

spdy-transport's Issues

Recommend Projects

Recommend Topics

Recommend Org

Jobs