SPDY parser.js tests #3
Conversation
… header (SYN_STREAM) for frame type 0x01 - L176
| @@ -172,7 +173,7 @@ Parser.prototype.onSynHeadFrame = function onSynHeadFrame(type, | |||
|
|
|||
| if (!isPush) { | |||
| callback(null, { | |||
| type: 'HEADERS', | |||
| type: 'SYN_STREAM', | |||
There was a problem hiding this comment.
This is going to break everything! ;) I did it for compatibility with HTTP2.
There was a problem hiding this comment.
So, am I interfering with your idea/plan? Feel free to enlighten me :)
There was a problem hiding this comment.
I'd go with just HEADERS for both SYN_STREAM and SYN_REPLY. HTTP2 is using just HEADERS for both of them, and for continuation headers too. There is no complexity in handling this in connection.js.
TL;DR - let's leave it as it is ;)
There was a problem hiding this comment.
Got it, does that mean that it sends back a HEADERS type code instead of the SYN REPLY? Didn't notice that, or does this just happens on the parsing part.
There was a problem hiding this comment.
The framer has them apart: requestFrame, responseFrame, headersFrame. The particular implementation chooses the right frame type.
|
Yay! |
|
What about the PUSH_PROMISE and PRIORITY? |
|
@diasdavid what about it? |
|
Is it a compatibility thing too? (The fact they are around on the spdy/parser.js) |
|
Yeah, exactly. The protocols should look completely the same to the |
…onforms with what connection.js expects
|
Hello @diasdavid ! Do you need any help with this? |
| }, done); | ||
| }) | ||
|
|
||
| it('should parse frame with http header and Unidirectional flag', function(done) { |
There was a problem hiding this comment.
When 0x02 = FLAG_UNIDIRECTIONAL is passed, nothing is declared on the frame parsed. Is this intended @indutny ?
There was a problem hiding this comment.
Just fixed it, thanks for reminding!
|
Any feedback on things that could be done to make this better? :) All tests pass now, code style is followed. Frames were extracted from go<->node experiments (which all of them worked :) ) |
| @@ -190,7 +190,7 @@ Parser.prototype.onSynHeadFrame = function onSynHeadFrame(type, | |||
|
|
|||
| if (!isPush) { | |||
| callback(null, { | |||
| type: 'HEADERS', | |||
| type: 'HEADERS', // type === 0x01 ? 'SYN_STREAM': 'SYN_REPLY', | |||
|
Looks pretty good except some style nits! Thank you! |
|
Awesome :) fixed all of the things you mentioned :) |
|
Landed in 4eb339b, thank you so much! |
|
wooo :D Awesome, thank you! |
Hi @indutny putting this here as a WIP. I (finally) got the test case working, however noticed that for a SYN_FRAME (type 0x01), the callback was being called with type being "HEADERS".
Also, found this - https://github.com/indutny/spdy-transport/blob/master/lib/spdy-transport/protocol/spdy/parser.js#L184 which I guess to be leftovers from http2, at least I can't find any reference on the SPDY spec about a PUSH_PROMISE type of frame. Same goes for PRIORITY https://github.com/indutny/spdy-transport/blob/master/lib/spdy-transport/protocol/spdy/parser.js#L191
Will continue working on the other frame tests, just wanted to keep you posted :)