[rdsubhas]

(These are just my opinions as web developer. Please feel free to downvote if my expectations are wrong)

While I can completely agree with the technical merits of this proposal, there are some very two-faced statements.

Author begins by pointing out the painfulness of IPv4 to IPv6, says that the next HTTP upgrade should be humble. But then proceeds to kill cookies and remove all the architectural problems in HTTP. Isn't that the same what IPv6 was? Wouldn't such an approach produce the same amount of pain to the implementors (that is us, the web developers)?

Any upgrade will certainly have some backward-incompatible changes. But if it is totally backward incompatible, I don't understand why it still needs to be called HTTP. Couldn't we just call it SPDY v2 instead, or some other fancy name?

Cookies are a problem. But the safest way to solve that problem is in isolation. Try to come up with some separate protocol extension, see if it works out, throw it away if it doesn't. But why marry the entire future of HTTP with such a do-or-die change?

I blindly agree with the author that SPDY is architecturally flawed. But why is it being advocated in such big numbers? Even Facebook (deeply at war with Google) is embracing it. It's because SPDY doesn't break existing applications. Just install mod_spdy to get started. But removing cookies? What happens to the millions of web apps deployed today, which have $COOKIE and set_cookie statements everywhere in the code? How do I branch them out and serve separate versions of the same application, one for HTTP/1.1 and another for HTTP/2.0?

More doubts keep coming... Problem with SPDY compressing HTTP headers? Use SPDY only for communication over the internet. Within the server's data center, or within the client's organization - keep serving normal HTTP. There are no bandwidth problems within there. Just make Varnish and the target server speak via SPDY, that is where the real gains are.

I could go on. I'm not trying to say that the author's suggestions are wrong. They are important and technically good. But the way they should be taken up and implemented, without pain to us developers, doesn't have to be HTTP/2.0. Good ideas don't need to be forced down others throats.

[phkamp]

No. Ipv6 is Ipv4 with bigger addresses, it didn't try to solve any of the other problems of IPv4 (or attempts to solve them were killed by ISPs).

One example was multihoming (having more than one ISP) serveral smart proposals were floated (anycast, nearcast etc) but they were killed by ISP's who protected a lucrative business.

If Ipv6 had made multi-ISP multihoming possible without all the trouble of BGP, business would have killed to get it back in the late 1990ies.

Cookies only disappear from the wire, they are trivial to simulate on your server (see my other reply here).

[jerf]

"Ipv6 is Ipv4 with bigger addresses,"

Yeah, I used to think that, then I participated in some IPv6 conversions and watched some others. I don't think that any more. IPv6 may not be the Glorious Solution to All Network Problems Ever, but it's not just the obvious incremental improvement on IPv4 either. It's a new protocol.

(I do sometimes wonder if an IPv4.1 that simply set a flag and used 8 bytes instead of 4 was proposed right now if it could still beat IPv6 out to the field even with IPv6's head start. Note, I'm not saying this would necessarily be a good idea, I just find myself wondering if IPv4.1 could still hypothetically beat IPv6 to deployment.)

[romaniv]

What practical problems, aside from address range exhaustion, does it solve? I've read some technical articles about benefits of IPv6, but most of them keep returning to address size problem.

[AnIrishDuck]

I think a big part of this is address range exhaustion is the root cause of many other problems. For example, IPv6 effectively obsoletes NAT, which removes all kinds of complexity from many protocols (off the top off my head: IPSec, many P2P protocols).

IPv6 also brings saner (IMO) protocol headers, and introduces a variety of other incrementally improved protocols (see ICMPv6, DHCPv6) that have been tweaked with the benefit of years of deployment experience.

[Tuna-Fish]

> More doubts keep coming... Problem with SPDY compressing HTTP headers? Use SPDY only for communication over the internet.

That's not good enough. The big problem is that you need the headers to properly route the request to the correct server. So for most operations, there will have to be one machine that is capable of reading all the headers of all the requests that arrive. gzipping the headers makes the job of this machine much, much harder.