-
Notifications
You must be signed in to change notification settings - Fork 4
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
Comments
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. :) |
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.comvar 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. OthersUnfortunately 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. |
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. |
I think SPDY 2 is still much more popular at the moment. |
hi hi - is this going to be possible? |
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. |
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
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?). |
determine if a URL is running spdy
The text was updated successfully, but these errors were encountered: