71–79 of 79 posts
Earlier quoted context omitted.
That's a XSS then :)
Does it matter? Do you actually care about your spdycheck session?
Cool, way too cool! Here are two resources we wrote to help get on with SPDY (shameless plug, though :(): http://blog.bubbleideas.com/2012/08/How-to-set-up-SPDY-on-ng... http://stackoverflow.com/questions/15152775/how-to-set-up-sp... We read quite many posts suggesting that SPDY doesn't help much but that's simply not true. At least in our case. If you're delivering assets over secured sockets layer, then SPDY is def…
I ran into this bug after enabling spdy in nginx and had to disable it. https://code.google.com/p/chromium/issues/detail?id=161751 Don't know, if it is a nginx thing, but all browsers had problems.
That's cool. Why isn't HN available over IPv6 though? Softlayer (the hosting provider HN appears to use) has supported it natively since 2011. It is pretty scummy that they charge for IPv6 allocations if you want more than the one address they give you though - I've never seen anyone else doing that - some providers even give you a /56 or /48 free or charge, but Softlayer charges $4 a month for a /64...
I ask in the most genuine way possible: Why? IPv6 is for when you can't get an IPv4 address anymore. To the best of my knowledge, there aren't currently users with only IPv6 addresses, so there's zero reason for us to support it. In the general case, why should any IPv4 website bother with IPv6? Is there any benefit?
- NATs are full of state, and state is messy. Making your site route around them may improve performance.
- This is one of the few areas where software people can directly make the world a better place, by preventing "our" Internet from regressing into something that more resembles the telco network.
- Lack of IPv6 support strains the credibility of companies that purport to be on the forefront of technology. Google, Facebook, and Wikipedia (and Bing?!) figured this out; why can't Hacker News?
- It gives your site a green 6 in IPvFoo, instead of a red 4. Six is 2 better than four, and green is 100THz better than red.
Earlier quoted context omitted.
I ran into this bug after enabling spdy in nginx and had to disable it. https://code.google.com/p/chromium/issues/detail?id=161751 Don't know, if it is a nginx thing, but all browsers had problems.
We haven't run into this, should be a configuration/version issue then.
news.ycombinator.com Does Not Support SPDY
SPDY Protocol Not Enabled!
Seriously?
This SSL/TLS server is using the NPN Entension to tell browsers it supports alternative protocols, but SPDY is not a protocol it supports.
The server is not making SPDY an option. Since all the pieces are in place, hopefully it will be easy to enable SPDY support with this server.
Earlier quoted context omitted.
SPDY has no benefit for mobile APIs. Make sure you turn on HTTP Keep-Alive and all your requests will be pipelined over a single TLS connection.
Why do you assert it has no benefit for mobile APIs? Here are a few that I can think of off the top of my head: * SPDY Multiplexing is superior to HTTP pipelining. Pipelining requires in-order responses, which leads to head of line blocking. * SPDY header compression is a win for mobile, since mobile uplink bandwidth is often a bottleneck. Request header compression allows for fitting more requests into fewer packets…
If you are going to dedicate resources to switching to SPDY, you should instead investigate protobuf.
* Almost all APIs are transactional. Your API should be returning all the data you need to render a single screen in your mobile app, or it is inefficient.
* You should be stripping all request headers except for User-Agent, and the server should be responding based on the known capabilities of the app version.
* Pings are not the correct way to deal with hangs. I don't want to spill any secret sauce here, but it should be obvious to anyone with low level TCP experience.
* Pipelining also uses a single connection. Opportunistic FINs are not unique to SPDY.
Earlier quoted context omitted.
Why do you assert it has no benefit for mobile APIs? Here are a few that I can think of off the top of my head: * SPDY Multiplexing is superior to HTTP pipelining. Pipelining requires in-order responses, which leads to head of line blocking. * SPDY header compression is a win for mobile, since mobile uplink bandwidth is often a bottleneck. Request header compression allows for fitting more requests into fewer packets…
Because SPDY is designed for quickly loading websites with lots of resources (the average page has 50-100 components). Just because it is new and fancy and from Google doesn't mean you should use it for other things that transport over HTTP/S. If you are going to dedicate resources to switching to SPDY, you should instead investigate protobuf. * Almost all APIs are transactional. Your API should be returning all the…
That said, I've got some comments on your new points:
* "Almost all APIs are transactional. Your API should be returning all the data you need to render a single screen in your mobile app, or it is inefficient." - Addressing this completely would take awhile, and there's no good point in our discussing this exhaustively. I'll simply note that while an API response may return all data necessary to render a single screen in the app, it does seem nice to allow for prioritized out of order responses like SPDY does. There does not seem to be a good reason to have head of line blocking in the responses, since the app should be able to render incrementally.
* "Pings are not the correct way to deal with hangs. I don't want to spill any secret sauce here, but it should be obvious to anyone with low level TCP experience." - I think you must be misunderstanding this, or it must not be obvious Google's TCP team, since they agree with the usage of SPDY PINGs. Perhaps you think SPDY PINGs are a keep-alive mechanism? Note that the article I linked to identifies them as a liveness detection mechanism.
* "Pipelining also uses a single connection. Opportunistic FINs are not unique to SPDY." - I don't know why you bring up pipelining again when I've pointed out that multiplexing is superior. Why put up with response head of line blocking? And I don't know what you're exactly referring to with opportunistic FINs, perhaps you can explain in further detail?
And I'll throw in extra data points. Despite the fact that you don't feel like it's useful for mobile APIs, other non-Google parties clearly do:
Square (https://github.com/square/okhttp has their Android SPDY implementation)
Twitter (https://github.com/jpinner has their SPDY developer's work on Netty, which they use in their mobile APIs)