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...
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.1host: foobar.comConnection: spdyable
Consensus :)
Basically, we just have to have enough people who think it is a good idea!
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 SPDYb) 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.
index.html is served over HTTP.if browser was spdyembedded links would be https // so browser will attempt spdyelseembedded links would be httpendif
On Fri, Nov 16, 2012 at 2:21 AM, Rajeev Bector <rbe...@gmail.com> wrote:index.html is served over HTTP.if browser was spdyembedded links would be https // so browser will attempt spdyelseembedded links would be httpendifPerhaps 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
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.
Rajeev
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.
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 =/
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.
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.
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 ?
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,
For first load yes. But A-P info is cached at the browser, so it doesn't happen again.
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.