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

Add SPDY test #2

Open
chrisueland opened this issue Jul 18, 2013 · 9 comments
Open

Add SPDY test #2

chrisueland opened this issue Jul 18, 2013 · 9 comments

Comments

@chrisueland
Copy link
Contributor

determine if a URL is running spdy

@bebraw
Copy link
Contributor

bebraw commented Jul 19, 2013

This one's actually a bit tough nut to solve. Can you provide me an example of an URL that is quaranteed to use SPDY and that does not use a fallback? Alternatively I could try to set up such a server on my own.

It would also be a good idea to understand how to check for SPDY. By examining a Firefox plugin I noticed it checks the header. Perhaps that is the key.

I am just going to need some nice way to test this. :)

@abh
Copy link

abh commented Jul 22, 2013

You need a SPDY client; it should be able to tell you if it can upgrade the connection or not. I haven't tried it, but a bit of google found this https://github.com/nasss/spdy-client

@bebraw
Copy link
Contributor

bebraw commented Jul 23, 2013

You need a SPDY client; it should be able to tell you if it can upgrade the connection or not. I haven't tried it, but a bit of google found this https://github.com/nasss/spdy-client

Yup. I actually tried out that specific client and submitted a pull request for it (redundant import). Unfortunately it doesn't work as well as it we need. I'll give you a couple of examples below so you can see what I mean and can verify my results (so it's not pebkac).

google.com

var client = require('./client');

var req = client.get({
    path: '/',
    url: '/',
    port: 443,
    host: 'google.com'
}, function(res) {
    console.log(res);
});

req.on('error', function(err) {
    console.error(err);
});

returns

{ frame:
   { type: 'SYN_REPLY',
     id: 1,
     version: 3,
     associated: 0,
     priority: 0,
     fin: false,
     unidir: false,
     _offset: 4,
     headers:
      { status: '400 Bad Request',
        version: 'HTTP/1.0',
        'content-length': '925',
        'content-type': 'text/html; charset=UTF-8',
        date: 'Tue, 23 Jul 2013 08:45:38 GMT',
        server: 'GFE/2.0' },
     url: '' },
  headers:
   { status: '400 Bad Request',
     version: 'HTTP/1.0',
     'content-length': '925',
     'content-type': 'text/html; charset=UTF-8',
     date: 'Tue, 23 Jul 2013 08:45:38 GMT',
     server: 'GFE/2.0' },
  httpVersion: 'HTTP/1.0',
  statusCode: 400,
  method: 'GET',
  url: '/' }

That looks okayish apart from the statusCode. It looks like the client might work.

Others

Unfortunately wordpress.com returns nothing. spdycheck appears to return results for it, though, so something is wrong. The same goes for cloudflare.com and americanexpress.com. facebook.com returns a result similar to above except the statuscode is 301.

It looks like the client works somewhat but it is not perhaps reliable enough for our usage given the results. Let me know if you think I am missing something obvious. Perhaps that spdycheck.org performs some magic behind curtains.

@bebraw
Copy link
Contributor

bebraw commented Jul 25, 2013

Is it enough for us to support just SPDY 3? If so, spdy-client should be enough for our purposes. It looks like those cases that failed, were using SPDY 2. In case of americanexpress.com, there was a SPDY capable server but the functionality had not been enabled yet. My guess is that the service maintains a lookup to figure out the capability based on server information provided at the site header.

@chrisueland
Copy link
Contributor Author

I think SPDY 2 is still much more popular at the moment.

@chrisueland
Copy link
Contributor Author

@jdorfman @abh @tjasko any ideas guys?

@chrisueland
Copy link
Contributor Author

hi hi - is this going to be possible?

@bebraw
Copy link
Contributor

bebraw commented Aug 6, 2013

It's probably possible. I think we may need to re-engineer that spdy-client library to support SPDY 2 as well. Alternatively we could try to find a solution implemented in some other language and then interface with that.

Given our requirements we can probably get away with a subset without having to implement the entire spec as we are interested only in knowing whether or not a server supports SPDY 2/3. I guess it's time to read the spec and see if we can get away with something minimal.

@bebraw
Copy link
Contributor

bebraw commented Sep 6, 2013

Hey, looks like SPDYCheck code is open source (C#, GPL). They also wrote a nice blog post about the service. Unlike expected they actually don't use a SPDY client. Instead they just seem to check response headers and infer it based on that. Would that be enough for our purposes?

I also studied spdy-client further. It looks like there's an argument for version hidden in the client. As wordpress.com supposedly supports only SPDY/2 I gave it a go using it. It failed to work, though.

Maybe it would make sense to do some sort of a combo? Do the same as SPDYCheck does and verify SPDY/3 using the client?

Could you specify the output for the /spdy resource? I'm guessing we could have something like this:

GET /spdy/urlgoeshere

['spdy2', 'spdy3']

That returns an array because it is possible to implement both SPDY/2 and SPDY/3 separately. There's also room for extension (SPDY/4?).

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

3 participants