CODEWITHSUNDEEP
spdynpn
Tyler Collier
Tyler Collier

Reputation: 11988

How can I detect, server side, if the client supports SPDY?

How can I detect, server side, if the client supports SPDY?

I want my website to be as fast as possible. Here's my thinking: (Note: my website does not need to transmit sensitive data.) If a browser connects to my website with HTTPS but it doesn't support SPDY , it'll be a waste. Unnecessary overhead due to HTTPS right? On the other hand, if the browser connects via HTTP and does support SPDY, that will be a missed opportunity.

It looks like NPN is the technology that the client and server use to negotiate on SPDY or not. That happens in the web server, before it ever hits my application code, right? I suppose then what I'd really need is a modified version of NPN (not even sure if that's really its own thing outside of SPDY) or mod_spdy. Ideally such a version would have an option called use_spdy_if_available_otherwise_redirect_to_http. :-)

Oh, and if all this isn't complicated enough, I'm currently using Cloudflare's CDN service. I'm pretty sure I have no recourse to modify how they operate in this regard, and thus have no chance, right?

Upvotes: 0

Views: 580

Answers (2)

anthumchris
anthumchris

Reputation: 9090

I agree with igrigorik's advice: do not redirect users from HTTPS to HTTP. That's just not cool. Regardless, I had this detection problem today and my answer's below.

In NGINX (I'm running 1.7.7), the $spdy variable will be set if the client connects with SPDY connection. Otherwise, $spdy will not have a value. For example, I'm passing a custom URL parameter to a php script:

server {
  listen 443 ssl spdy;
  ...
  ...

  # add SPDY rewrite param
  if ($spdy) {
    rewrite ^/detect-spdy.js /detect-spdy.js.php?spdy=$spdy last;
  }
  # fallback to non-SPDY rewrite
  rewrite ^/detect-spdy.js /detect-spdy.js.php last;

  # add response header if needed later 
  add_header x-spdy $spdy;
}

Upvotes: 0

igrigorik
igrigorik

Reputation: 9611

All data is sensitive: the sites you visit, the pages you've viewed, etc. By aggregating this data across many pages, you can infer a lot about the user: their intent, interests, and so on. Hence, we need HTTPS everywhere. For more, see our Google I/O talk [1] on the subject.

In terms of detecting SPDY support, yes you want to use NPN/ALPN (ALPN is a successor [2]). The client sends a ProtocolNameList in their handshake, which advertises which protocols they support. Most servers will use this to auto-negotiate SPDY, but if you want to control this decision yourself, you'd have to modify your server implementation to invoke some sort of callback when the secure handshake is being performed.

That said, given what I said earlier about HTTPS everywhere, I would advise you against this altogether. Use HTTPS everywhere and let the browser and server auto-negotiate SPDY if its supported.

Upvotes: 2

Related Questions