detecting spdy enabled clients

[Rajeev Bector]

So I understand that if you speak HTTPS, you can detect spdy enabled browser by looking at whats offered with NPN. However - if you are serving markup over HTTP and you want to serve different markups for spdy-enabled browsers vs otherwise, is there a clean way to do this ? 

I am thinking that we can use the version numbers offered in User-Agent but its kinda clunky and not sure that it will work reliably in cases such as mobile. Anyone has thoughts  and/or experience with this ?

TIA,

Rajeev 

[Roberto Peon]

Within JS you can do something like this:

  var probably_using_spdy = ((window.location.protocol != "http:") ||

                     window.chrome.loadTimes().wasFetchedViaSpdy);

and then generate a new query or something...

This is far, far better than doing probing based on user-agent.... bleh.

If people are finding this to be a common request, having the client putt something in the connection header-line for (at least) the first request on a connection could be an option...

-=R

[Rajeev Bector]

Thanks for the quick response Roberto. See inline ...

On Thursday, November 15, 2012 4:51:32 PM UTC-6, Roberto Peon wrote:

Within JS you can do something like this:

  var probably_using_spdy = ((window.location.protocol != "http:") ||

                     window.chrome.loadTimes().wasFetchedViaSpdy);

and then generate a new query or something...

This is far, far better than doing probing based on user-agent.... bleh.

Not sure. One - this is chrome specific and two - this means i have to do bunch of js stuff to change the embedded links on the client side. 

 

If people are finding this to be a common request, having the client putt something in the connection header-line for (at least) the first request on a connection could be an option...

The use-case is that  you may only want to do spdy/ssl for embedded links and not the main markup. In many situations, the main markup is served over a different domain than your static objects, for example  so serving both over spdy (if  you do NOT want SSL otherwise) is going to hurt performance because you are going to setup 2 SSL/spdy sessions. In addition, this makes it operationally convenient.

Care to elaborate this solution ?

Thanks again,

Rajeev

[Roberto Peon]

Oh sure.

The idea is simple:

Add "spdyable" (or some other string, hopefully shorter) to the Connection: line (which is a good idea, because it'd be stripped if you're going through a proxy).

e.g.

GET / HTTP/1.1

host: foobar.com

Connection: spdyable

-=R

[Rajeev Bector]

On Thursday, November 15, 2012 5:20:06 PM UTC-6, Roberto Peon wrote:

Oh sure.

The idea is simple:

Add "spdyable" (or some other string, hopefully shorter) to the Connection: line (which is a good idea, because it'd be stripped if you're going through a proxy).

e.g.

GET / HTTP/1.1

host: foobar.com

Connection: spdyable

Sounds like something like this will do the trick (altho need to think some more on any other ramifications of it). What does it take to  "bless" this ? 

[Roberto Peon]

Consensus :)

Basically, we just have to have enough people who think it is a good idea!

-=R

[Rajeev Bector]

On Thursday, November 15, 2012 5:35:21 PM UTC-6, Roberto Peon wrote:

Consensus :)

Basically, we just have to have enough people who think it is a good idea!

This is sounding like IETF :). Does a short draft need to be written explaining the use-case and the proposed solution. If yes, I dont mind writing it. If anyone else on the list has thoughts on whether this problem is *interesting* enough to be solved (or otherwise), please chime in. 

[Roberto Peon]

I think all that is needed is to solicit whether people anticipate if something like this solves a common problem.

I can believe it is, but I'm only one person.

-=R

[Ilya Grigorik]

I'm not sure I follow this use case.. If you're asking to mix SPDY and non-spdy resources on your page then:

a) you're going to get a mixed content warning if the main page is over SPDY

b) you're better off going with one connection ("unshard") and delivering over SPDY

Querying via JS - the first thing that Roberto suggested - seems to do what you want.. Writing a small shim library to take care of different browser API's is not hard.

Finally, if you want to know whether connection was made via SPDY and you're behind a proxy like Apache / Nginx.. then they already add an extra header to indicate that the proxied (HTTP) request will be mapped to SPDY.

ig

[Rajeev Bector]

On Friday, November 16, 2012 1:21:09 AM UTC-6, Ilya Grigorik wrote:

I'm not sure I follow this use case.. If you're asking to mix SPDY and non-spdy resources on your page then:

a) you're going to get a mixed content warning if the main page is over SPDY

b) you're better off going with one connection ("unshard") and delivering over SPDY

The use-case is if the main page is not delivered over SPDY but some of the static objects are. So in this case there is no mixed-content warning issue I believe.  

 

Querying via JS - the first thing that Roberto suggested - seems to do what you want.. Writing a small shim library to take care of different browser API's is not hard.

The shim can probably be done.  My thinking was that rejigging links on the client side should be avoided if possible (if nothing else - its painful if you have tons of different pages and js, where u need to do this).  Regardless, I'll research this more.

 

Finally, if you want to know whether connection was made via SPDY and you're behind a proxy like Apache / Nginx.. then they already add an extra header to indicate that the proxied (HTTP) request will be mapped to SPDY.

Useful to know but  thats not the scenario I am talking about. Again, the scenario is : 

index.html is served over HTTP.

if browser was spdy

embedded links would  be https // so browser will attempt spdy

else

embedded links would be http

endif

Rajeev

[Ilya Grigorik]

On Fri, Nov 16, 2012 at 2:21 AM, Rajeev Bector <rbe...@gmail.com> wrote:

index.html is served over HTTP.

if browser was spdy

embedded links would  be https // so browser will attempt spdy

else

embedded links would be http

endif

Perhaps I'm still missing something then.. but that's exactly what will happen today -- assuming your server supports NPN, then SPDY will be negotiated. 

Besides, I don't think this is a use case we want to promote. You don't win much by mixing HTTP 1.1 / HTTP 2.0 / SPDY semantics in one page.

ig 

[Rajeev Bector]

On Friday, November 16, 2012 10:10:24 PM UTC-6, Ilya Grigorik wrote:

On Fri, Nov 16, 2012 at 2:21 AM, Rajeev Bector <rbe...@gmail.com> wrote:

index.html is served over HTTP.

if browser was spdy

embedded links would  be https // so browser will attempt spdy

else

embedded links would be http

endif

Perhaps I'm still missing something then.. but that's exactly what will happen today -- assuming your server supports NPN, then SPDY will be negotiated. 

Hmm.. I guess one of us is surely missing something.  Let me try to describe in a different way :  The question is "how do you implement the if statement above cleanly at the time of serving index.html (which is served over HTTP)".  I'd like to avoid presenting HTTPS embedded links if its not going to be going over SPDY.

 

Besides, I don't think this is a use case we want to promote. You don't win much by mixing HTTP 1.1 / HTTP 2.0 / SPDY semantics in one page.

There is LOTS of infrastructure deployed over HTTP/1.1 and I think its operationally cumbersome to change all of it in one shot. So though I understand the rationale of "not promoting it" (to some extent), the question is of "supporting it" and not promoting it.

Thanks again ! 

Rajeev

 

ig 

[Ilya Grigorik]

On Sat, Nov 17, 2012 at 10:19 AM, Rajeev Bector <rbe...@gmail.com> wrote:

Hmm.. I guess one of us is surely missing something.  Let me try to describe in a different way :  The question is "how do you implement the if statement above cleanly at the time of serving index.html (which is served over HTTP)".  I'd like to avoid presenting HTTPS embedded links if its not going to be going over SPDY.

Oh. Well, that's User-Agent detection.. It's not hard to build a list of UA's and version pairs which support SPDY, and match against that. No extra headers required.

ig

[Rajeev Bector]

Yes and that's my current plan but I don't really like it since it's not very clean

Rajeev

[Ryan Hamilton]

Alas UA sniffing is not good enough for this.  Chrome, for example, does not speak SPDY 2% of the time.  (This lets us collect metrics about HTTP vs SPDY).  Instead, have you considered having the server emit the Alternate-Protocol: header?  This is how a server can tell the client that the same content can be fetched via SPDY from a different port.

I think this is exactly what you are looking for...

[William Chan (陈智昌)]

Not true anymore. See http://crrev.com/154584. If there's no correctness problem with occasionally getting this wrong, I'd be OK with UA sniffing. I don't want us to be tied into a situation where it's required for some reason. But I'd also just rather the main document be served over HTTPS anyway :)

[Ryan Hamilton]

Hey, cool!  Go go gadget SPDY :>  That being said, what do you think about the use of Alternate-Protocol for this purpose?

[William Chan (陈智昌)]

Totally works.

[Rajeev Bector]

I am not sure if Alternate-Protocols works for this because in the use-case I am talking about - the main doc is served on a different domain than the embedded docs (think of the situation where the embedded static objects are served over a different domain by a CDN).

Rajeev

[William Chan (陈智昌)]

It works. The CDN would have to use A-P here for that domain.

Perhaps you've got an implicit requirement that these subresources be served via SPDY on first visit? It's true that A-P would not allow that. That's always been one of the issues with A-P though, so I don't count that as A-P not working. But it might not work for your use case if you've got a requirement.

[Rajeev Bector]

On Sunday, November 18, 2012 1:54:14 PM UTC-6, William Chan wrote:

It works. The CDN would have to use A-P here for that domain.

Perhaps you've got an implicit requirement that these subresources be served via SPDY on first visit? It's true that A-P would not allow that. That's always been one of the issues with A-P though, so I don't count that as A-P not working. But it might not work for your use case if you've got a requirement.

The layers of onion keep coming off ! Here I go again :).

So really the best way to model this is the following : there are two CDNs  cdn_a and cdn_b. cdn_a is today's CDN and does NOT serve SPDY (or for that matter, tls).  A new cdn, cdn_b is built out. Now, I'd like to choose cdn_a if spdy is not going to happen and cdn_b otherwise.  So, I think AP will not help solve that problem. Correct ?

Now, getting back to a more basic question about AP. If my page has 50 HTTP links - all to the same domain (different 3rd level domains for sharding), how does AP behave ? Does the "upgrade" happen for every single one of them ?  Browser could make many parallel connections before even the existence of AP is realized. No ?  So, then how do they all go over "a single spdy connection".

 
Rajeev

[William Chan (陈智昌)]

Ah, interesting setup! You're absolutely correct, in your setup A-P will not help.

For the domain sharded example, unless you have a wildcard certificate, SPDY will not be able to employ connection sharing for these sharded connections.

Sounds like you're back to UA sniffing, which I hate =/

[Rajeev Bector]

For the domain sharded example, unless you have a wildcard certificate, SPDY will not be able to employ connection sharing for these sharded connections.

Lets say there are 48 links to 8 different shards. (foo1.bar.com, foo2.bar.com, ... foo8.bar.com) and they all share the cert. I am still somewhat confused about how AP would behave. In the presence of all this concurrency where browser it obviously trying to establish parallel connections, is there a predictable behavior of AP that can be counted upon ?

Sounds like you're back to UA sniffing, which I hate =/

Yes, likewise. I think we should still explore the possibility of "Connection:spdy" idea that Roberto had. Its seems like a very clean solution.

Rajeev

 

[William Chan (陈智昌)]

On Sun, Nov 18, 2012 at 2:38 PM, Rajeev Bector <rbe...@gmail.com> wrote:

For the domain sharded example, unless you have a wildcard certificate, SPDY will not be able to employ connection sharing for these sharded connections.

Lets say there are 48 links to 8 different shards. (foo1.bar.com, foo2.bar.com, ... foo8.bar.com) and they all share the cert. I am still somewhat confused about how AP would behave. In the presence of all this concurrency where browser it obviously trying to establish parallel connections, is there a predictable behavior of AP that can be counted upon ?

You'd have to connect to each domain first over HTTP, and get the A-P header which says that the domain support NPN-SPDY on port 443. Once that happens, then if there's a wildcard cert and the domains point to the same IP, then the browser will share the SPDY connection.

Sounds like you're back to UA sniffing, which I hate =/

Yes, likewise. I think we should still explore the possibility of "Connection:spdy" idea that Roberto had. Its seems like a very clean solution.

I am unclear how that would work. A Connection: spdy header would be stripped out by most hops, since HTTP intermediaries aren't going to understand it. I think you're arguing for a new HTTP request header that would advertise NPN-SPDY support that would *not* be stripped out by intermediaries. This reminds me of HTTP client hints or Browser Hints.

[Rajeev Bector]

You'd have to connect to each domain first over HTTP, and get the A-P header which says that the domain support NPN-SPDY on port 443. Once that happens, then if there's a wildcard cert and the domains point to the same IP, then the browser will share the SPDY connection.

Which makes it (obviously) very undesirable.
 

Sounds like you're back to UA sniffing, which I hate =/

Yes, likewise. I think we should still explore the possibility of "Connection:spdy" idea that Roberto had. Its seems like a very clean solution.

I am unclear how that would work. A Connection: spdy header would be stripped out by most hops, since HTTP intermediaries aren't going to understand it. I think you're arguing for a new HTTP request header that would advertise NPN-SPDY support that would *not* be stripped out by intermediaries. This reminds me of HTTP client hints or Browser Hints.

 

It sounds to me you *want* a header that is not fwded by the intermediaries. No ? if the intermediary does not speak spdy, this should not be fwded. No ?

Rajeev

 

[William Chan (陈智昌)]

On Sun, Nov 18, 2012 at 5:07 PM, Rajeev Bector <rbe...@gmail.com> wrote:

You'd have to connect to each domain first over HTTP, and get the A-P header which says that the domain support NPN-SPDY on port 443. Once that happens, then if there's a wildcard cert and the domains point to the same IP, then the browser will share the SPDY connection.

Which makes it (obviously) very undesirable.

For first load yes. But A-P info is cached at the browser, so it doesn't happen again.

 

 

Sounds like you're back to UA sniffing, which I hate =/

Yes, likewise. I think we should still explore the possibility of "Connection:spdy" idea that Roberto had. Its seems like a very clean solution.

I am unclear how that would work. A Connection: spdy header would be stripped out by most hops, since HTTP intermediaries aren't going to understand it. I think you're arguing for a new HTTP request header that would advertise NPN-SPDY support that would *not* be stripped out by intermediaries. This reminds me of HTTP client hints or Browser Hints.

 

It sounds to me you *want* a header that is not fwded by the intermediaries. No ? if the intermediary does not speak spdy, this should not be fwded. No ?

HTTP intermediaries and NPN-SPDY/TLS intermediaries are not the same. The use of TLS for NPN-SPDY will, in the absence of MITM proxies, create an end to end connection from the client to the origin, thereby skipping any HTTP level intermediaries in between, which may not speak SPDY. Note that today SPDY capable browsers will speak to SPDY capable servers over TLS despite HTTP intercepting intermediaries not speaking SPDY.

PS: Just because I'm explaining how A-P functions, it doesn't mean I don't think the best solution isn't switching entirely to HTTPS.

[William Chan (陈智昌)]

On Sun, Nov 18, 2012 at 5:18 PM, William Chan (陈智昌) <will...@google.com> wrote:

On Sun, Nov 18, 2012 at 5:07 PM, Rajeev Bector <rbe...@gmail.com> wrote:

You'd have to connect to each domain first over HTTP, and get the A-P header which says that the domain support NPN-SPDY on port 443. Once that happens, then if there's a wildcard cert and the domains point to the same IP, then the browser will share the SPDY connection.

Which makes it (obviously) very undesirable.

For first load yes. But A-P info is cached at the browser, so it doesn't happen again.

 

 

Sounds like you're back to UA sniffing, which I hate =/

Yes, likewise. I think we should still explore the possibility of "Connection:spdy" idea that Roberto had. Its seems like a very clean solution.

I am unclear how that would work. A Connection: spdy header would be stripped out by most hops, since HTTP intermediaries aren't going to understand it. I think you're arguing for a new HTTP request header that would advertise NPN-SPDY support that would *not* be stripped out by intermediaries. This reminds me of HTTP client hints or Browser Hints.

 

It sounds to me you *want* a header that is not fwded by the intermediaries. No ? if the intermediary does not speak spdy, this should not be fwded. No ?

HTTP intermediaries and NPN-SPDY/TLS intermediaries are not the same. The use of TLS for NPN-SPDY will, in the absence of MITM proxies,

I just re-read my statement of TLS for NPN-SPDY. Heh, that sounds weird. Perhaps we should have named the alternate protocol something other than NPN-SPDY, oops.

[Patrick McManus]

I think we're butting into the use case the dns srv stuff the ietf wg is talking about is going to help with.

[Rajeev Bector]

For first load yes. But A-P info is cached at the browser, so it doesn't happen again.

Thats good to know. Although the static objects I am talking about here, also get cached so its really the first-load performance that we are talking about :).  BTW, is the AP-info-cache persistent ?

 

It sounds to me you *want* a header that is not fwded by the intermediaries. No ? if the intermediary does not speak spdy, this should not be fwded. No ?

HTTP intermediaries and NPN-SPDY/TLS intermediaries are not the same. The use of TLS for NPN-SPDY will, in the absence of MITM proxies, create an end to end connection from the client to the origin, thereby skipping any HTTP level intermediaries in between, which may not speak SPDY. Note that today SPDY capable browsers will speak to SPDY capable servers over TLS despite HTTP intercepting intermediaries not speaking SPDY.

Ah right. How did I miss that ! So HTTP intermediaries (transparent or configured) are not a problem.  

 

PS: Just because I'm explaining how A-P functions, it doesn't mean I don't think the best solution isn't switching entirely to HTTPS.

Its not always about what's the best. Its about what's workable in a decent time frame. HTTPS for page-level serving requires a lot of re-work in many scenarios with mixed-content warnings, 3rd-party ad/content and all that. 

Cheers,

Rajeev

[Rajeev Bector]

I am not plugged into that. Let me look that up.

[Tyler Collier]

It's been almost 2 years. Is there a good answer for Rajeev's question now?

I'm in his boat: if someone connects to my site with http, and I know they can do SPDY, I want to force https. If they can't, then I don't want the overhead of SSL. How can I detect it server-side?