-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Creating client streams #1
Comments
Have you tried: |
@indutny we should be able to open a stream without a Nevertheless, I tried adding a proper header from the go client. The header got parsed correctly, but it failed since it expected
If I remove the
But the expected was to get "Writing to stream" instead of undefined. From the client:
|
You meant this?
I'm quite sure that there is not much point in creating stream without The reason why I do it this way is that I'm polyfilling between HTTP2 and SPDY, to make sure that this transport library behaves in completely same way when using any of these protocols. |
That is part of the HTTP layering over SPDY, so it shouldn't be mandatory for the framing layer, right? It is true that we can always make path be "/", and method "GET" and open the stream anyways. Although it may look odd, it should definitely work good enough. |
I don't think that HTTP layering could be viewed separately from the SPDY spec.
|
Ok, what I just done is following. Framer now defaults to GET and |
rad :) Would there a problem if the server assumed so too? So that it offers free interop with docker/spdystream (and other possible SPDY framing layer impl?) Right now I'm running into a issue where I can connect a go spdystream client to a spdy-transport server, but a node spdy-transport client to a spdy-transport server breaks on the client. # https://github.com/diasdavid/spdy-cross-test/blob/master/node/client.js
» node client.js
/Users/david/Documents/Code/ipfs/spdy-transport/lib/spdy-transport/protocol/spdy/framer.js:98
this.compress.write(block.render(), callback);
^
TypeError: Cannot read property 'write' of null
at Framer.headersToDict (/Users/david/Documents/Code/ipfs/spdy-transport/lib/spdy-transport/protocol/spdy/framer.js:98:16)
at Framer._synFrame (/Users/david/Documents/Code/ipfs/spdy-transport/lib/spdy-transport/protocol/spdy/framer.js:176:8)
at Framer.requestFrame (/Users/david/Documents/Code/ipfs/spdy-transport/lib/spdy-transport/protocol/spdy/framer.js:211:8)
at Connection.request (/Users/david/Documents/Code/ipfs/spdy-transport/lib/spdy-transport/connection.js:459:26)
at Socket.<anonymous> (/Users/david/Documents/Code/go-projects/src/spdy-cross-test/node/client.js:11:10)
at Socket.g (events.js:199:16)
at Socket.emit (events.js:104:17)
at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1001:10) |
I'm afraid that you will need to call Guess, I'm going to re-work it eventually, sorry for this! |
Nevermind, I was using the version where I had changed the 'HEADERS' type to 'SYN_STREAM' and therefore breaking everything™ |
@indutny I believe I get why I can't fully establish a go spdystream to a node spdy-transport connection, spdy-transport server never replies to a SYN_STREAM with a SYN_REPLY and so in go spdystream, the stream never assumes a ready state, but in the node spdy-transport, it seems that implementation doesn't wait to receive that message to start writing to it. |
@diasdavid hm... do you call |
OH! Well, I tried with stream.respond() and without it, but now that you asked, I remembered of putting the stream.write() call inside the stream.on('readable') event and it worked. if I call stream.write right after stream.respond, the write never gets to the client. I went in such a twist of supposed Shouldn't there be a better way to know when the stream is available to write than .on('readable'), because this means that if the client never writes something, I cannot tell that I can start writing. Update: No need anymore to wait for .on('readable') due to: b5c02c3 |
@indutny can you enlighten me on how to proper create a client stream?
Have been tried to get
spdystream
(go version) andspdy-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-L13As 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:
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.The text was updated successfully, but these errors were encountered: