HN supports SPDY
31–40 of 79 posts
Re: HN supports SPDY
#32Has anyone built an NSURLProtocol subclass for SPDY? I did a quick GitHub search and found nothing. Seems to me that's one big use case that SPDY could dramatically improve, is all these native mobile apps which open SSL connections to their APIs.
Re: HN supports SPDY
#33Just noticed that the indicator turned on :) https://addons.mozilla.org/En-us/firefox/addon/spdy-indicato...
Here is the SPDY indicator I use for Chrome. It's also simple and works well. https://chrome.google.com/webstore/detail/spdy-indicator/mpb...
All this when the code is a one-liner:
chrome.extension.sendRequest({ spdy: window.chrome.loadTimes().wasFetchedViaSpdy });
It's not the extension's fault, but Google's. I guess they want us to get used to ignoring the scary permissions?(Also, wouldn't it be good if the Chrome store had a link to the developer / source? All I could find on there was a username 'rauchg')
Re: HN supports SPDY
#34Great! Now if only they would implement allowing HEAD requests and support for any of the various headers that would allow me to get a 304. The reason I ask is because every time my Safari crashes, if I have 50 HN tabs open (as I often do on by Friday [1]) I'll get IP banned from HN because Safari will do a GET request on each page, but it can't pass any of the headers necessary to get back a 304, because HN doesn't…
Isn't that how everyone uses HN?
Re: HN supports SPDY
#35Great! Now if only they would implement allowing HEAD requests and support for any of the various headers that would allow me to get a 304. The reason I ask is because every time my Safari crashes, if I have 50 HN tabs open (as I often do on by Friday [1]) I'll get IP banned from HN because Safari will do a GET request on each page, but it can't pass any of the headers necessary to get back a 304, because HN doesn't…
That behavior shouldn't get you banned, but some of your requests will get dropped if you make too many too quickly. You will see 304s for static resources, like images and CSS. Efficiently handling HEAD requests for dynamically generated pages is actually painful, and many frameworks support it by handling the request like a GET and just omitting the body. In our case, most pages contain fnids and will never be the…
Re: HN supports SPDY
#36Great! Now if only they would implement allowing HEAD requests and support for any of the various headers that would allow me to get a 304. The reason I ask is because every time my Safari crashes, if I have 50 HN tabs open (as I often do on by Friday [1]) I'll get IP banned from HN because Safari will do a GET request on each page, but it can't pass any of the headers necessary to get back a 304, because HN doesn't…
That behavior shouldn't get you banned, but some of your requests will get dropped if you make too many too quickly. You will see 304s for static resources, like images and CSS. Efficiently handling HEAD requests for dynamically generated pages is actually painful, and many frameworks support it by handling the request like a GET and just omitting the body. In our case, most pages contain fnids and will never be the…
And I'm aware of how painful it is to handle HEAD requests for a dynamic page, having had to deal with it on reddit. There are some easy hacks to make it work pretty well. One is to just keep a cache of the last update time of each page, and then use that cache when you get a HEAD request.
I'm not sure what an fnid is, but if you have something on the page that changes so quickly that the hash changes when the content doesn't, then I'd contend you're doing something wrong.
Re: HN supports SPDY
#37Great! Now if only they would implement allowing HEAD requests and support for any of the various headers that would allow me to get a 304. The reason I ask is because every time my Safari crashes, if I have 50 HN tabs open (as I often do on by Friday [1]) I'll get IP banned from HN because Safari will do a GET request on each page, but it can't pass any of the headers necessary to get back a 304, because HN doesn't…
> The way I consume HN is I load up HN once or twice a day, open up all the interesting links and their comment pages in new tabs, and then go back to work. By that time most pages are probably updated, so you wouldn’t get any 304s anyway. Since recent update, Firefox behavior is to only reload restored tabs on demand. This avoids that issue. https://blog.mozilla.org/blog/2012/06/05/firefox-has-a-redes...
Actually, quite the opposite. HN comment pages seem to peter out at about 12 hours in most cases, and after that you'll rarely see a new comment, so really the content stops changing after about a day.
Re: HN supports SPDY
#38Just noticed that the indicator turned on :) https://addons.mozilla.org/En-us/firefox/addon/spdy-indicato...
Re: HN supports SPDY
#39It 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...
Re: HN supports SPDY
#40Great! Now if only they would implement allowing HEAD requests and support for any of the various headers that would allow me to get a 304. The reason I ask is because every time my Safari crashes, if I have 50 HN tabs open (as I often do on by Friday [1]) I'll get IP banned from HN because Safari will do a GET request on each page, but it can't pass any of the headers necessary to get back a 304, because HN doesn't…
Isn't that how everyone uses HN?