Skip to content
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

Twitter test suite fails #4

Closed
novabyte opened this issue Feb 16, 2014 · 15 comments
Closed

Twitter test suite fails #4

novabyte opened this issue Feb 16, 2014 · 15 comments

Comments

@novabyte
Copy link

I've compiled the master branch and when I run tests with make tests I get the following error report:

TEST INFO: 1 test(s), 1 case(s) in 1 suite(s)

Testing Desktop.gun.twitter_SUITE: Starting test, 1 test cases

=ERROR REPORT==== 16-Feb-2014::20:06:52 ===
Ignored GOAWAY control frame 0 protocol_error

- - - - - - - - - - - - - - - - - - - - - - - - - -
twitter_SUITE:spdy failed on line 58
Reason: timeout
- - - - - - - - - - - - - - - - - - - - - - - - - -

Testing Desktop.gun.twitter_SUITE: *** FAILED test case 1 of 1 ***
Testing Desktop.gun.twitter_SUITE: TEST COMPLETE, 0 ok, 1 failed of 1 test cases
@essen
Copy link
Member

essen commented Feb 19, 2014

That's just Twitter closing the connection on us for the reason "ok", I will have to look in more details as to why at some point.

@essen
Copy link
Member

essen commented Feb 21, 2014

This is a bug I reported before in the SSL application. :( Twitter switched to HTTP/2.0 draft 9 by default and the SSL application fails to select the next protocol (spdy/3) so it's stuck with that...

@essen
Copy link
Member

essen commented Feb 28, 2014

Okay. It's not a bug in the SSL application! \o/ It was a bug in older docs. :( So when I wrote the code initially I used the wrong type for an option (as the docs told me to) and of course it got ignored by the SSL code. Fixing the type (almost) make it work again.

That's not the only issue with Twitter though. They do not advertise spdy/3 anymore. They do spdy/3.1 though, so I'll just have to go over that and make it work (just changing the advertising should be enough as they only dropped stuff we didn't use). I'll do it soon, I'm focusing on finishing gun_http first.

@essen
Copy link
Member

essen commented Feb 28, 2014

Personal reminder that I need to add spdy/3.1 to Cowboy too.

@novabyte
Copy link
Author

Thanks for tracking this down @essen

@essen
Copy link
Member

essen commented Feb 28, 2014

You'll have to thank Ingela too when you see her. :-)

@Prots
Copy link

Prots commented Apr 9, 2014

Maybe it's the same bug, but when I execute

{ok, ServerPid} = gun:open(<<"github.com">>, 443),
Stream = gun:get(ServerPid, <<"/">>),
gun:await(ServerPid, Stream).

always get {error,timeout}. With google sites too =(
How fix this problem, please help!?

@jur0
Copy link

jur0 commented Apr 9, 2014

If you use lists ("github.com", "/") instead of binaries, it might help.

@Prots
Copy link

Prots commented Apr 9, 2014

No, without binaries get {error,undef}.

@jur0
Copy link

jur0 commented Apr 9, 2014

It works for me:

15> {ok, ServerPid} = gun:open("github.com", 443).
{ok,<0.72.0>}
16> Stream = gun:get(ServerPid, "/").
#Ref<0.0.0.141>
17> gun:await(ServerPid, Stream).
{response,nofin,200,
          [{<<"server">>,<<"GitHub.com">>},
           {<<"date">>,<<"Wed, 09 Apr 2014 16:04:18 GMT">>},
           {<<"content-type">>,<<"text/html; charset=utf-8">>},
           {<<"status">>,<<"200 OK">>},
           ...

@essen
Copy link
Member

essen commented Apr 9, 2014

Works for me too, just tried.

@essen
Copy link
Member

essen commented Apr 9, 2014

Getting a timeout when using binaries indeed. But I think that's because of the hostname. I'll look.

@essen
Copy link
Member

essen commented Apr 9, 2014

Yep that's because you pass the host as binary. Use a string and it should work, and if it doesn't please open another ticket with more details (steps to reproduce etc.).

As for the path, using a binary there is no problem. Thanks!

@Prots
Copy link

Prots commented Apr 9, 2014

Cowlib hadn't started, so app didn't work. I opened a new ticket.

@essen
Copy link
Member

essen commented Jun 3, 2014

Fixed all issues mentioned here as far as I know. Closing, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants