#HTTP #HTTP2.0 Why that version number is so very important ....
It's no surprise that HTTP is the new TCP. Inarguably, more applications are delivered via HTTP than any other. That's including mobile apps, by the way, which are more often than not using HTTP to talk to REST-based APIs on the app side.
But what we don't often say is that HTTP 1.x is the new TCP. That distinction is important (some might say imperative) as HTTP 2.0 moves toward becoming the official, ratified standard.
You see, backwards compatibility is not something that's part and parcel of HTTP 2.0 any more than it was for IPv6. Like its IP cousin, HTTP 2.0 is designed to move the web forward toward a faster, more secure application world.
But in doing so, it made some choices that make it incompatible with previous versions of HTTP.
Now, that means you can't just move to a new web server that supports HTTP 2.0 and expect it to work. Clients may support HTTP 2.0 and they may not. If they don't, they're out of luck. Worse, the problem isn't just client compatibility and support, it's your apps you've got to worry about, too.
Apps that make the choice to use absolute location references, e.g. http://mysite.com/myresource, will need to change. In the new world of HTTP 2.0, HTTPS is the new TCP, not HTTP. That's problematic, because according to our data, only 30% of apps are secured using SSL. The rest are strictly HTTP. That means a lot of apps are going to need something to transition to the next generation of web protocols.
One of those options is rewriting every app to make sure they're using relative URIs, e.g. /myresource. Rewriting apps is an expensive proposition, not just from the cost of throwing developers at them, but at the cost of not being able to work on other, perhaps more critical and competitive, apps.
This is one case where technical debt rears its ugly head and demands to be serviced.
Clearly, like IPv6, a transitory approach that leverages gateway technology will be necessary to avoid all the technical debt of HTTP 1.1 overwhelming the desire to adopt HTTP 2.0 and its security and performance benefits.
That's why recognizing that HTTP 1.1 is the new TCP is so important. Just because they share a common name doesn't mean they're the same. The move to HTTP 2.0 is going to time - and technology.
