

HN Discusses: Lets talk about replacing HTTP in the browser. - bradhe

HTTP has been a solid workhorse for, what, 20 years? It can pretty much be considered ubiquitous -- any platform worth its salt has a robust HTTP client. HTTP is reasonably light weight and extensible and is generally well understood.<p>But is it still appropriate for "modern" uses? As web apps become more and more interactive, larger, and have different constraints on connectivity is there a better alternative to base our stack on?<p>We have a few interesting solutions to those problems that have been built on top of HTTP. Comet, for instance, overcomes the interactivity bit and web sockets could be cool if it ever get full support but those both seem like hack-y solutions -- solutions that required a lot of energy that likely could have been mitigated if we used a different protocol in the first place.<p>Lets just consider, for the purposes of this discussion, what the ideal technology would be. We don't necessarily need to talk about adoption or deployment or feasibility -- obviously its pretty damn infeasible to ACTUALLY replace HTTP thanks to its ubiquity -- but just ideally, what would you like to see?<p>Anyone know if any feasibility studies or scoping of a technology has been done on this topic?
======
yanw
The SPDY protocol is a potential replacement: <http://www.chromium.org/spdy/>

~~~
bradhe
Yeah, that is kind of what sparked this thought in my mind...there are a
couple of things that are good here. Multiple files per request is a pretty
cool idea and server-initiated requests could solve a lot of problems.

One thing that immediately comes to mind as a bummer about SPDY, though: Lack
of native full-duplex duplex communication.

