6 ms·
OMG really? Do we want to make HTTP even bigger? Don't we want to dump it for good and look for something more suitable to what the modern web needs instead?
by bromagosa 15y ago
OMG really? Do we want to make HTTP even bigger? Don't we want to dump it for good and look for something more suitable to what the modern web needs instead?
- gujk 15y agoWhat do you propose we do in he meantime, before all the existing servers and clients are migrated?
- uriel 15y agoI propose HTTP 0.2, a subset of HTTP 1.1 with some simple extensions: http://http02.cat-v.org http://http02.cat-v.org
- Hoff 15y agoRewriting a large and complex enterprise-class application is tough enough, and a task that can variously (and expensively) fail. Rewriting the whole of the World Wide Web? Your replacement had better have a solid compatibility and migration path with "legacy" HTTP, and provide a substantial improvement over what HTTP and the existing tools provides, and clients and a migration path for a majority of the platforms and tools and browsers and embedded browsers and embedded web servers in use, and the budget and the time to make the replacement push.
- sanxiyn 15y agoGoogle is trying: http://www.chromium.org/spdy http://www.chromium.org/spdy
- stanleydrew 15y agoSPDY isn't really intended to replace HTTP I don't think, it's just speeding it up quite a bit. All the messages exchanged between client and server are still HTTP when using SPDY.
- wvenable 15y agoNo, SPDY replaces HTTP but keeps many of the same high-level semantics. The messages are not HTTP; for example, the headers are a binary format and compressed which isn't possible with HTTP.
- stanleydrew 15y agoWell technically HTTP as an application-layer protocol is unchanged. So I don't really understand your comment. The messages are HTTP. Whether the headers are compressed by an underlying protocol (such as SPDY) doesn't seem to be relevant.
- wvenable 15y agoAn application layer protocol is the layer above TCP and defines the formats of those messages over that transport. Other application layer protocols are, for example, FTP, DNS, and SMTP. SPDY and HTTP have completely different (and incompatible) message formats even though they are meant for the same task. And it isn't HTTP tunneled through SPDY; there are significant differences. For example, although SPDY supports HTTP methods (GET, POST, PUT) the method and parameters are specified as headers in the request. Also, all the header names are lower-cased in SPDY. The client and server don't communicate by a single stream as in HTTP but instead communicate in frames over the stream that can contain multiplexed requests and responses. At the very high level, you might be able to build an API that could handle web requests and responses over HTTP or SPDY interchangeably but that API isn't "HTTP".
- stanleydrew 15y agoI don't really want to argue about the semantics of OSI and what is or isn't an application layer protocol. I'll just point you to Google's own diagram of where SPDY fits in which is in the "SPDY design and features" section of the whitepaper here: http://www.chromium.org/spdy/spdy-whitepaper http://www.chromium.org/spdy/spdy-whitepaper. Here's the text from that section: "SPDY adds a session layer atop of SSL that allows for multiple concurrent, interleaved streams over a single TCP connection. "The usual HTTP GET and POST message formats remain the same; however, SPDY specifies a new framing format for encoding and transmitting the data over the wire."
- icebraining 15y agoWhy exactly do you say HTTP is unsuitable for the modern web? If anything, the problem is that we don't abide by it enough. More codes - which, by the way, do not increase the size of the packets - are better for the "modern web", the one where REST APIs are being adopted and which has more and more automated clients which require computer readable information.