Slashdot Mirror
HTTP 2.0 Will Be a Binary Protocol
earlzdotnet writes "A working copy of the HTTP 2.0 spec has been released. Unlike previous versions of the HTTP protocol, this version will be a binary format, for better or worse. However, this protocol is also completely optional: 'This document is an alternative to, but does not obsolete the HTTP/1.1 message format or protocol. HTTP's existing semantics remain unchanged.'"
HTTP is the world's most popular protocol and it's bloated and slow to parse.
It's nice to have a link to the draft. But couldn't we have just a little more "what's new" than it's binary? This is slashdot... Filled with highly techincal people. At least a rundown of the proposed changes would be very helpful in a discussion. The fact that they're proposing a binary protocol doesn't really matter to anyone besides anyone who wants to telnet to a port and read the protocol directly.
Makes it harder to troubleshoot by using telnet to send basic HTTP commands, and speedily develop applications with nuts and bolts tools over plaintext -- but the tradeoff is it can transfer a ton of data over one TCP socket, greatly simplifying the network layer of HTTP, and most certainly adding a lot of performance. For webserver admins, this will make life a lot easier.
Can't wait to use the new 046102 047111 005113 tag!
I deny that I have not avoided attaining the opposite of that which I do not want.
Isn't the HTTP 2.0 spec based on Google's SPDY protocol? It is basically just HTTP 1.1 but with header compression and the ability to either send or hint that extra files will be needed.
I am not big on my networking protocols, but didn't the HTTP 2.0 group decide to base its work on Google's SPDY protocol? The two don't look the same to me, but some of the descriptions in this spec do look like reshuffled versions of the SPDY spec. What's the relationship between the two these days?
Breakfast served all day!
The big change is allowing multiplexing in one stream. It's a lot like how Flash multiplexes streams.
It's nice to have a link to the draft. But couldn't we have just a little more "what's new" than it's binary? This is slashdot... Filled with highly techincal people. At least a rundown of the proposed changes would be very helpful in a discussion. The fact that they're proposing a binary protocol doesn't really matter to anyone besides anyone who wants to telnet to a port and read the protocol directly.
from quick glance, multiple transfers and communications channels("streams" in the drafts lingo) can be put through the single connection, cutting tcp connection negotiations.
world was created 5 seconds before this post as it is.
This is FAR from a done deal. The binary/ASCII question is being hotly debated.
the joys of debugging x.400 and reading a x.409 dump *NOT*
Why is it that news Internet standards seem to want to go down the route that the OSI did -
HTTP/2.0 defines stream multiplexing, framing, stream control, prioritizing - pretty much replicating TCP. What is the point of putting TCP-like protocol on top of TCP ?
At this point, some people will have the urge to rise and scream "Inner platform effect! Anti-pattern!" But consider that HTTP is like opening a separate port for every URL, so that you're no longer limited to having one instance of an application listen for connections.
How does this benefit anything? I was under the assumption that most http traffic is compressed (usually gzip I think,) so while the ability to read the http directly exists easily, most transmissions were already binary, at least for the payload. How does making the headers and stuff binary benefit us that much? We're talking what .... maybe 2% of the entire message being optimized?
I'm an admin, not a app/web developer, so if someone knows, can you explain it in non-RFC terms that even those not familiar with the tech can understand?
Application-level multiplexing avoids repeating TCP slow start when the user agent starts downloading additional resources in parallel, such as style sheet, script, and images, or when the user agent stops a download before it has finished.
Seems it's going binary to have EVERYTHING be a stream, with frame based communications, different types of frames denoting different types of data and your "web app" responsible for detecting and handling these different frames. Now I get that there's a lot of demand for something more than Web Socket, and I know that non-Adobe video streaming such as HLS are pathetic, but this strikes me as terrible.
Really, why recraft HTTP instead of recrafting browsers? Why not get Web Socket nailed down? Is it really that hard for Google and Apple to compete with Adobe that instead of creating their own Streaming Media Services they need HTTP2.0 to force every server to be a streaming media server?
Adobe's been sending live streams from user devices to internet services and binary based data communication via RTMP for several years, but HTML5 has yet to deliver on the bandied about "Device API" or whatever it's called this week even though HTML5 pundits have been bashing on Flash for years.
So if Adobe is really that bad and Flash sucks that much, why are we re-inventing HTTP to do what Flash has been doing for years?
Why can't these players like Apple and Google do this with their web browsers, or is it because none of these players really wants to work together because no one really trusts each other?
At the end of the day, we all know it's all just one big clusterfuck of companies trying to get in on the market Adobe has with video and the only way to make this happen in a cross-platform way is to make it the new HTTP standard. So instead of a simple text based protocol, we will now be saddled with streaming services that really aren't suited to the relatively static text content that comprises the vast majority of web content.
But who knows, maybe I'm totally wrong and we really do need every web page delivered over a binary stream in a format not too different from what we see with video.
One giant leap backwards :(
from quick glance, multiple transfers and communications channels("streams" in the drafts lingo) can be put through the single connection, cutting tcp connection negotiations.
HTTP 1.1 can already do multiple transfers, browsers are already doing "streams". I doubt the gains to be made from doing that in binary are going to be noticeable.
No sig today...
Why does it have to be Binary?
That's so twentieth century.
We should be using a Hexadecimal format!
"A person is smart. People are dumb, panicky dangerous animals and you know it." - K
One thing I've always wanted to see out of HTTP is a saved state between hits. 1 KB of headers in each frame isn't horrible, but the overhead of verifying an authentication cookie on every hit can be.
Am I reading this right that in section 6.2, headers only happen at the beginning of a stream and do not happen on each individual request? That sure would make my life a little nicer!
What part of the term "HyperTEXT" did the working group fail to understand?
Really, outside of snooping/privacy discoveries, this is the SINGLE WORST piece of news I have seen in 15 + years on Slashdot. We could see this coming with the push for DRM in the HTTP spec. Here we watch the other shoe drop.
"They" don't like this web. They are entrenched media and information companies, and the elite financial and political powers that rely on framing/controlling public information - while collecting rents for doing so.
You think that your issues with security and control of your own platform are bad now? Wait til your browser is rejected by sites you need to do business with - because you won't parse HTML/HTTP 2.0. Linking this with crap like Intel TPM/TXT and you are well into Orwell Telescreen territory.
"Optional"? Five years from now, we'll all see if you can get your driver's license, pay your phone bill or shop at Amazon without this one...
"Flyin' in just a sweet place,
Never been known to fail..."
The rationale for http-2.0 is available in the http-bis charter. Quoting the spec:...
As part of the HTTP/2.0 work, the following issues are explicitly called out for consideration:
It is expected that HTTP/2.0 will:
I remember reading about this a while ago when I discovered SPDY, and from what I understood is that in SPDY/HTTP2.0, the multiple transfers can be multiplexed. So rather than Connection A requesting resource 1 and then requesting resource 2 etc, it could theoretically request 'all resources I need to render this page above the fold' or something. Then those resources come down simultaneously. When the last one is finished, the page can display.
This would definitely save some overhead for re-requesting resources in the same connection.
Sure, you could help currently by inlining as much as you can and using CSS sprites to reduce image resource requests, but this way would keep things more modular/separated...
Why won't they focus on what really matters? HTTP is still missing sane authentication techniques. Almost all websites require users to log in, so it should be a priority that a log in mechanism be supported in HTTP as opposed to being the responsibility of every web developer individually (don't you dare mention HTTP Basic Authentication). Relying on cookies alone to provide authentication is a joke. Not all websites afford to buy certificates or the performance penalty of HTTPS and security over HTTP is practically non-existent.
The HTTP protocol is very primitive and it has not evolved on par with the evolution of cryptography and security. A lot better privacy, confidentiality, authentication can be obtained with very little cost. Because most websites allow you to log in, the server and the client share a common piece of information that a third party does not, namely the client's password (or some digest of that). Because of this shared information, it should be far easier to provide security over HTTP (at least for existing users). I find it laughable that we still rely on a piece of fixed string sent as plain-text (the session cookie) to identify ourselves. Far better mechanisms exist (besides the expensive HTTPS) to guarantee some security, and it should not be the responsibility of the web developer to implement these mechanisms.
At the very least, HTTP 2.0 should support password-authenticated key agreement and client authentication using certificates.
While signing up can still be problematic in terms of security, logging in need not be. There's a huge difference between being exposed once and being exposed every time. If there was no Eve to monitor your registration on the website, then there should be no Eve that can harm you any longer. You have already managed to share some secret information with the server, there is no reason to expose yourself every time you log in by sending your password in plain text and then sending a session in plaintext every time you make a request. That is, a session which can be used by anyone.
While it may be acceptable for HTTP1.1 to not address such security concerns, I would find it disturbing for HTTP2.0 not to address them either.
To get an intuitive idea on how easy it can be to have "safer proofs" that you are indeed logged in, consider the following scenario: you have registered to the website without an attacker interfering; you would like to log-in, so you perform an EKE with the server and you now have a shared secret; every time you send a request to that website, you send some cookie _authenticated = sha2(shared_key || incremental_request_number). Obviously, even if Eve sees that cookie, it cannot authenticate itself in the next request, because it does not know the shared_key and thus cannot compute the "next hash".
This is just an example proof-of-concept technique to get an idea on how much better we can do. Many other cheap techniques can be employed. This one has the overhead of only one hash computation.
Given that HTTP is a tremendously used protocol, it does make sense to make it as space-efficient as possible, being responsible for a large portion of the bandwidth. I do believe it matters on a large scale. However, given the arguments above, this should not be their priority.
I think it is stupid. Anywhere it matters, the data is compressed anyway. Binary encodings actually probably tend to hurt rather than help compression.
It is the default mechanism for bypassing firewalls. It is becoming a replacement for tcp/ip. Historically you would simply have opened connections on other ports but that's obviously excruciatingly painful in a firewalled environment.
So, pretty soon firewalls will be either blocking port 80, or performing packet inspection and ripping out streams they don't like.
Guess it will keep the firewall developers busy.
multiplexing like a intelligent switch would be great for programming designers...
And if you're going to complain that "hamburgers" must be beef... I'm going to argue they should be "ham."
Nope. A hamburger sandwich should be a sandwich made out of people from Hamburg Germany. B-)
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Looks like we're going to have a lot more Wireshark users :)
from quick glance, multiple transfers and communications channels("streams" in the drafts lingo) can be put through the single connection, cutting tcp connection negotiations.
So, errm SCTP then...
http://blog.nexusuk.org
Slight correction here, The current Internet Draft that is sighted is not a standard yet (i.e. not an RFC). IF this draft is accepted by the IETF, and published as an RFC, then HTTP 2.0 would be a binary protocol. Since the Internet Draft is a working group draft, it will most likely advance and become an RFC standard, but that is not an automatic process.
Embrace...Extend...Extinguish.
I come here for the love
but you might not get it.
There seems to be a lot of posters on Slashdot who do not get just how useful it is that HTTP is text based. I rarely ever need to look at the raw TCP dumps. With the prevalence of REST APIs these days, viewing TCP dumps is overkill. You could argue that REST is a fad and we should all go back to binary RPC protocols, but HTTP is very nice because it allows you to debug so easily. Other posters have mentioned this ease of debugging only to be countered by the binary is just as easy crowd, so I'll go further and provide a worked example.
I use the following code snippet to debug HTTP. It's not the best example of code, but I use it regularly and it works. With it, I can write up the HTTP request in any text editor and shove it up the network and have the response printed out to console for inspection. An example of a HTTP request is like so. This returns a response that's human readable.
It's all nice and human readable. Could I do the same with a raw TCP frame? Sure. I could download it to disk and fire up some viewer like wireshark. Text is far more convenient as I could view it right in my terminal.
Unix, when it was new, was radical in that everything was in ordinary ascii text files. Everyone else "knew" that you had to work in binary, have binary config databases, binary file systems with dozens of record type and so on. With each binary format you had to provide a binary editor and/or debugger. If something broke, you needed a high priest of that particular religion just to debug it, much less fix it.
Note how many Unixes you see for each machine running GCOS or PRIMOS. Of all the machines of the day that still exist, note that most z/OS files are simple EBCDIC. Over time, that square wheel quietly went away.
When the PC came along, application designers once again started doing everything in binary, plus the occasional DOS text file. If something broke, you needed to go back to the vendor, because programs didn't come with binary editors. Or you could get a high priest of a particular order to take it apart in a debugger.
And, just to add injury to insult, a 64-bit binary floating point zero is four times the length of an ascii zero followed by a space or newline. Spreadsheet files in binary were ~ 4 times larger that the ones in DOS text my company used (;-)) Turns out spreadsheet files are mostly empty, or mostly contain zeros.
Over time, lots of config files and data files became ascii or UTF-8, and a huge number fo data files became html or xml text files. And that square wheel went away.
Let a hypertext file be a sequence of bytes, separated by newline characters. Let the text be a sequence of bytes, optionally using multiple bytes per character, as in UTF-8.
Verily I say unto you, let it be simple, lest it be stupid. Round wheels are better than square, or ones that are just flat on one side
--dave
davecb@spamcop.net
It is the default mechanism for bypassing firewalls. It is becoming a replacement for tcp/ip. Historically you would simply have opened connections on other ports but that's obviously excruciatingly painful in a firewalled environment.
So, pretty soon firewalls will be either blocking port 80, or performing packet inspection and ripping out streams they don't like.
Guess it will keep the firewall developers busy.
Already doing that... Everything hijacking HTTP/HTTPS is turning out to be an almighty pain in the arse for sites that need to filter their web access (e.g. schools). As an example, we have Skype, which either requires the ability to make connections on port 443 to arbitrary IP addresses, or requires the firewall to ahve *all* unprivalidged ports open... Great design. (Yeah, I've got customers who want to use Skype but want to restrict web accesses to a walled garden - you can imagine how well that doesn't work.)
http://blog.nexusuk.org
Classic slashdot, can't even RTFA.
Exactly. It is useful to be able to demonstrate that a given request/response occurs with minimal interference. Otherwise there is always questions as to whether FireFox or Curl is sending a request 'differently' somehow; being able to show that a given behavior is reproducible with a request issued over least-common-denominator telnet is inarguable.
Additionally, telnet is nearly ubiquitous while protocol analyzers are much harder to find, plus are often forbidden on desktops in large corporate environments as a security issue either due to their sniffing capability or for innate vulnerabilities.
why do you guys think the payload returned back wouldn't be as human readable and the headers printable by a simple utility?
why would you need to view the raw frames? that's pointless. most people use stuff like curl for debugging/doing test requests anyways.
world was created 5 seconds before this post as it is.
Does anyone know how this proposal relates to Google's work on SPDY and QUIC? SPDY does multiplexing, and QUIC extends that to essentially re-implement TCP in a fashion that is optimized for web traffic.
I should go read the spec, but I'm hoping that someone who already has will post a summary.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
There's almost nothing about English that makes it special, but I wouldn't recommend documenting the spec in Klingon. (To be fair, you agree that binary is a bad idea.) Or hey, would could use APL for the reference implementation!
Intrinsically, you are correct: there's nothing much special about text. But the significance of text isn't intrinsic: it is extrinsic. Text is special because it's standard. We have a rich selection and history of tools, techniques, idioms and sober experience to draw on when it comes to dealing with text. With a new binary format we would have none of that. Your imagined translator has a lot of work to do before it can match up to the existing capabilities of text-oriented tools, let alone exceed them. Unnecessary binary formats effectively fork the development infrastructure.
If you ask me, it makes about as much sense as replacing the Roman alphabet with Chinese idiograms for English. Chinese characters are for more information dense: you can fit more on a page and you can read it faster. In many respects it's more efficient (it has even proven effective as a shared written form for diverse spoken dialects). That doesn't make it a good idea, regardless of the availability of translators.
We have plenty of historical examples of text protocols providing advantages over their binary equivalents. Do we have any good examples of the opposite: in which a binary protocol replaced a text protocol and proved superior by virtue of being binary?
An HTTP/1.1 persistent connection allows downloading only one resource at a time. Bringing up multiple persistent connections requires multiple TCP slow starts. And the only way to stop a transfer in progress is to kill the connection, which incurs another TCP slow start as the connection is brought back up.
Badly. It does multiple transfers in a pipeline if the server supports it, or else it falls back to basic keep-alive if the server is believed to be broken.... The problems, however, are manifold.
First, the browser must ask for each piece. With a more modern protocol, the browser asks for index.html, and the server says, "Okay. Here's index.html, and oh, BTW, here are the eight hundred images, CSS files, and JavaScript resources that you'll need in order to render it. HAND." The benefit comes from not having multiple cycles of request, parse, request more, parse, request more, parse, etc.
Second, the connection can do only one thing at once. If the HTML content comes from a script (and thus may be generated relatively slowly), the browser might get a partial HTML page with a bunch of images, but unless it opens a second connection to the server, it can't request those images until the entire blob of HTML has arrived. The browser sets limits as to how many connections it will open to a single server at once, so as soon as you have more than a couple of connections in that "data partially sent" state, any other requests are blocked waiting for those requests to complete. Couple this with just enough packet loss and/or latency to cause degenerate TCP behavior, and you have a recipe for terrible performance.
By contrast, a protocol that can say, "Oh, I've just sent part of an HTML file, and it contains twelve IMG tags; I'm providing you with the images interleaved with the HTML data" does not have this problem. No new connections are required; the images get sent while the script is continuing to scream at the database, "Give me data!" And although packet loss still impacts the arrival of the end of the stream, at least you don't have a multiplicative effect as you would if each of the image requests begins until the end of the stream.
And so on. There are very good reasons for upgrading the protocol. With that said, IMO, using a binary format is unnecessary. You could just as easily send a text string that says "Stream: 1\nChunk-length: 4096\n\n" followed by 4096 bytes of data, a newline, and a similar blob for the next stream. The overhead difference is likely to be negligible proportional to the data.
Check out my sci-fi/humor trilogy at PatriotsBooks.
True, CSS reduces network traffic for subsequent page views, as does putting most of your site's script in a separate file. But for the first page view, it's another connection to download the style sheets and scripts alongside the images. And there's a reason they call it a "first impression"; if first page view is too slow, expect viewers to bounce.
Sarcasm aside, the question then becomes one of whether your debugging tool is correct.
The space of paths is far bigger than the space of registerable port numbers, and overzealous firewalls have a habit of blocking port numbers.
Shouldn't it be called HBTP then? You know, HyperBinary Transfer Protocol.
Free Manning, jail Obama.
Use a compression layer, but DO NOT go binary. There is not much to gain this way. The Windows crowd never gets this, but it is one of the reasons UNIX and friends is still around.
Now I just need to know how to block all uses of HTTP 2.0 on my servers and clients.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
It's a win in spreadsheets and anything with sparse matrices.
It's a wash in text, as you'd imagine,
It's a lose in databases, which are almost always data-intensive,
It's horrid if you are encoding bit patterns in something like base-50.
We did a number of sanity-tests before using it in Ability, and later did a check using customer data that had been given to us, from which comes the characterization above.
--dave
davecb@spamcop.net
It would be better if HTTP as such were deprecated in favour of HTTPS. Efficiency is not a big problem and becomes less and less of an issue as there will always be bigger, faster systems (and besides the bloat of HTTP traffic is nothing to do with the HTTP protocol and the proportion of protocol to payload is going down not up). However, confidentiality and trust is becoming more and more of an issue.
"Okay. Here's index.html, and oh, BTW, here are the eight hundred images, CSS files, and JavaScript resources that you'll need in order to render it. HAND."
Somewhere during that time, browser wants to say, oops, I don't have a plugin to display that content. Or I don't want images. Or, my user is on mobile connection and doesn't want to see objects larger than 5kb. Skip this, and continue with the things I can process.
No way for the browser to say this in the "new" scheme of things, supposedly for the "good" of mobile users, who have one of the main uses for NOT displaying some items server wants to show, mobile bandwidth being what it is.
Bingo Dictionary - Pragmatist, n. A myopic idealist.
And conversely, just because a format is "text based" does not guarantee it is human-readable or doesn't suck. Take XML for instance. The insanely low signal-to-noise ratio makes it, for all intents and purposes, non-human-readable. I've seen many binary formats that would take less effort to interpret manually than many typical large XML files. Of course, all other things being equal, text-based is highly preferable.
Binary formats DO have to be parsed and converted. They come in a particular endianness, or as a pure bitstream/bytestream (think JPEG/MPEG/etc.), with particular (mis)alignment of data (think Windows bitmaps), etc. Any code that directly interprets such data as a C structure is incorrect. Of course language features may be available in some languages to directly declare "on the wire" data structure types, but that's essentially just automated parsing. In general, parsing text is easier than parsing binary, because it's easy to get binary parsing wrong while still having it work on your own system, whereas text parsing has to be done at least partly right to work at all.
Does anyone see the "advantage" of such protocol towards a more controllable DRM? (like DVD vs Blueray)
--- I am known for the ones who want to find me on the net. Is that a privacy risk or a privilege? One might wonder..
Use a compression layer, but DO NOT go binary. There is not much to gain this way.
What makes that any different from the already existing (gzip) compressed html ?
--- I am known for the ones who want to find me on the net. Is that a privacy risk or a privilege? One might wonder..
Actually, unless they've removed the functionality in their divergence from SPDY, the browser does have the ability to cancel individual items, I think, though that might be limited only to items specifically requested by the browser, in which case that's a rather silly and arbitrary flaw in the protocol.
Check out my sci-fi/humor trilogy at PatriotsBooks.
The word "its" is possessive, as in:
The chimpanzee scratched its head.
"it's" is a contraction of "it is".
It appears as if your sentence should have read:
Sadly as slashdot has no edit function available in its interface, it's a pointless exercise.
FTFY, and as AC said, please try and make an effort. Thank you! ;-)
With all this discussion about different types of detail and complexity, and the need to do massive coding to properly handle all forms of HTML headers, I'm reminded of a discussion I had once with a back-end designer.
He had made a system designed to work via http. When I asked why, and mentioned all the overhead and everything, he had a real simple response.
Essentially: the application wasn't a full powered web server. In it's simplest form, an http request is "open a socket, write a string, read a string, close socket". By designing it to look like http, and work over port 80, it fits into modern corporate systems, gets past most firewalls, etc.
The result? Sure, you could send crazy http thingies to this server; it would just return an error. But it was able to work with the expected use case -- send data to the server, get a response back. Plain text. Easy to work with.
What happens to such a system once everything becomes binary? No longer so simple.
Does this help the typical user? If the concern is over the per-file TCP overhead/startup, there is already a way to re-use a single TCP connection for multiple file transfers. If the concern is over the size of the headers, there is a much better way to ... you know, remove all the junk, cookies, extra headers, etc, than just trying to shrink text labels down (which is about all you can do if you want to keep the data content the same). If the concern is over "Perceived browser speed", well, let me remind you of Larry Wall's "rn" versus the previous dominant news reader -- and how "rn" would parse and display on the fly, instead of having to read the entire thing in before displaying. Or compare Safari to Firefox -- again, firefox starts displaying faster than Safari, so I can start reading the page sooner. Or, compare ....
Do not assume that "perceived slowness" is caused by a bad protocol.
It may be caused by a bad user agent.
If the page has to be fully loaded before being displayed, that's one thing.
If you can load the entire base text of a page, put it up, and then go back and start loading the images, or sounds, or flash thingies, that's another.
If you don't like all the screen jumping, well guess what? You can open a bunch of separate TCP/http connections, read just enough from each to determine size, and then stop reading -- let the socket data stop coming -- and put up the text of the page, the placeholders for what you need, and then, once the base information is up, then go back and read the rest without the "jumping" and resizing.
Does any of this require binary?
The goals of 2.0:
1. Substantially and measurably improve end-user perceived latency in most cases, over HTTP/1.1 using TCP.
That's a user agent behavior problem.
3. Not require multiple connections to a server to enable parallelism, thus improving its use of TCP, especially regarding congestion control.
That requires a way to say "Here is control data", and "Here is content data". Sure, that would help a great deal, if as a user agent, while reading a text blob for a web page, I see that I need to open a TCP channel for an image to determine it's size. I currently have to either wait for the web page text to finish, or open a new TCP channel to get the image. What can avoid this? If I am now having to send ACK's and NACK's back to the server during my read, I can also send a "Put on hold -- now give me Y instead". So this is a "win" for this behavior -- I can now reuse the same TCP channel, and get the beginning of another data stream, determine size, etc, and then get back to the first file. So clearly, this goal is a good goal, right? There are no flaws in the goal of using a single TCP channel to send multiple data streams, right?
Right?
No one could possibly see any flaws with transmission speed by saying that the sender is going to stop sending, and come to a complete halt until the receiver has synchronized, right?
It's a tradeoff. The old way re
Binary formats had only one advantage, and that was that you could read them directly into a C struct. But even then, that advantage disappeared when portability became an issue. That elegant fread into a struct, whatever, turns into a rat's nest when you have to deal with big endian vs lil endian, differing integer sizes... parsing text is a pain in the rear, but it is a less of a pain in the rear than looking at some binary data in the debugger wondering what went wrong.
This is my sig.
Ok, so the browser doesn't know the 800 images, CSS, javascript etc. that it will need to render the page. But it can cancel the individual item it knows nothing about? Genius. Your ideas intrigue me and I would like to subscribe to your newsletter.
Bingo Dictionary - Pragmatist, n. A myopic idealist.
But it was just following SMTP's lead...
Remember one of the reasons (I'm sure there were others) SMTP won over X.400 was developers could telnet to port 25 and do their thing...
Until the day a new 'Protocol-aware telnet 2.0' translates user-entered commands to binary protocols on-the-fly, a binary HTTP 2.0 is a bad idea.