Am I missing something? Do some people have so many cookies that this makes a difference or something?
Hello HTTP/2, Goodbye SPDY
91–100 of 181 posts
Re: Hello HTTP/2, Goodbye SPDY
#92Earlier quoted context omitted.
That's so lame. It's so easy to set up a new website today, it's going to be a huge burden in the future. Some of us still make websites for fun, not as businesses. I guess I have to buy a cheap ssl certificate from some sleezy website every time I feel creative.
I'm puzzled, did you miss the announcement? The EFF, Mozilla, and others are creating a CA that will give free certs to everyone: https://letsencrypt.org/
Re: Hello HTTP/2, Goodbye SPDY
#93Earlier quoted context omitted.
> that doesn't mean you can ship it without regards for the the standards process. It's still wrong for all the usual reasons. What Google is doing with PNaCl is the standards process. Standards start life by being not-standards that someone shipped and enough people liked to make it into a standard. There is nothing wrong here, nothing whatsoever. This is exactly how the process should work. Design-by-committee stan…
While I agree with you that competition is crucial, and without experimentation we will get nowhere, it is worth remembering that IE6 and all of its specific behaviors "won" through "raw competition". Often things win not through fair competition. For example, WebSQL "won" on mobile because WebKit won on mobile, and WebKit happened to have WebSQL. If WebKit had had, say, the Audio Data API (which it did not), then th…
It is worth noting that the findings in the antitrust actions in the US over Microsoft's illegal and anti-competitive behavior in establishing IE's dominance indicate that that claim is, at best, misleading.
Re: Hello HTTP/2, Goodbye SPDY
#94Can someone explain to me the actual upside of header compression? I work on a fairly major educational site and calculating now our request + response headers comes out to 1,399 bytes. Gzipping them they come out to 1,421 bytes. A small net increase. Am I missing something? Do some people have so many cookies that this makes a difference or something?
This would benefit from the fact that in one request headers are not repeated, but over multiple requests they certainly are.
http://www.greenbytes.de/tech/webdav/draft-ietf-httpbis-head...
Re: Hello HTTP/2, Goodbye SPDY
#95Earlier quoted context omitted.
> This attitude is exactly how you make sure that nothing ever changes or improves. On the contrary, we are in a desperate need of such attitudes in software. We need for everyone to stop jumping to every new thing with silly promises. We need to start choosing quality over quantity. We need substantial well researched improvements.
I think you're confusing quantity as being the end result. The quantity is about experimentation. The quality comes as the winning products are refined over time; the low quality products never gain mass traction and are discarded. That's exactly how it should work. These things are complimentary, not mutually exclusive. That process is how innovation happens quickly. It's also how you frequently discover new things…
Re: Hello HTTP/2, Goodbye SPDY
#96Does anyone know if Cloudflare has plans to implement HTTP/2? RIght now they support SPDY. I found the answer from their blog: "Part of the service CloudFlare provides is being on top of the latest advances in Internet and web technologies. We've stayed on top of SPDY and will continue to roll out updates as the protocol evolves (and we'll support HTTP/2 just as soon as it is practical)."
Re: Hello HTTP/2, Goodbye SPDY
#97Can someone explain to me the actual upside of header compression? I work on a fairly major educational site and calculating now our request + response headers comes out to 1,399 bytes. Gzipping them they come out to 1,421 bytes. A small net increase. Am I missing something? Do some people have so many cookies that this makes a difference or something?
So to answer your question: Header compression as employed in HTTP 2.0 helps if you do many requests with similar headers on the same connection.
Re: Hello HTTP/2, Goodbye SPDY
#98Earlier quoted context omitted.
> This attitude is exactly how you make sure that nothing ever changes or improves. On the contrary, we are in a desperate need of such attitudes in software. We need for everyone to stop jumping to every new thing with silly promises. We need to start choosing quality over quantity. We need substantial well researched improvements.
I think you're confusing quantity as being the end result. The quantity is about experimentation. The quality comes as the winning products are refined over time; the low quality products never gain mass traction and are discarded. That's exactly how it should work. These things are complimentary, not mutually exclusive. That process is how innovation happens quickly. It's also how you frequently discover new things…
Re: Hello HTTP/2, Goodbye SPDY
#99Earlier quoted context omitted.
Not really a fair benchmark. It's making tons of requests with tiny payloads, so that most browsers will hit a connection limit and requests will be queued up. Heavily optimized pages like google.com use data urls or spritesheets for small images, and inline small css/javascript. On the bright side, reducing the need to minimize request count will make our lives as developers a bit easier :-)
Many of the sites I visit frequently are exactly like that: tons of requests with tiny payloads. The nytimes.com homepage makes 100+ requests to tiny images. Same thing for the yahoo.com homepage. An ebay.com listing page makes many requests to small thumbnails of items on sale. And so on... This makes it a perfectly fair benchmark IMHO.
- Counting images can be misleading, since well-optimized sites use spritesheets or data URIs.
- If you're using something like Chrome's dev console to view requests, a lot of them are non-essential requests which are intentionally made after the page is functional.
- HTTP connection caps are per host. The benchmark is making hundreds of requests to one host, whereas a real page might make a dozen requests to the main server, a dozen to some CDN for static files, and a dozen to miscellaneous third parties.
- The benchmark is simulating an uncached experience; with a realistic blend of cached/uncached, HTTP 1 vs 2 performance would be much more comparable.
HTTP/2 is an improvement but if people expect a "5-15X" difference, they're in for a big disappointment.
Re: Hello HTTP/2, Goodbye SPDY
#100Earlier quoted context omitted.
I'm puzzled, did you miss the announcement? The EFF, Mozilla, and others are creating a CA that will give free certs to everyone: https://letsencrypt.org/
It's not live yet.