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!
I see a world where layout is delivered as it is now, and HTTP 2.0 is used for back-end communications. Streaming in content or responding to interactivity, and just generally being used to apply state to our currently stateless world.
The big change is allowing multiplexing in one stream. It's a lot like how Flash multiplexes streams.
Hey, Microsoft -- see what they did here? THAT'S how you make a radical update to a computer standard or interface without pissing off your users.
Now admit you have to eat the whole crow, not just a nibble or two, and give us Win 8.2 or 9.0 that lets users banish Metro to the binary hell from which it crawled.
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 :(
They should make HTML a binary format too and implement DRM to HTTP protocol....... That'll teach'em!
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!
It will be to those running large, hell, even medium sized sites.
Every single bit counts when you multiply that bit by 10,000, 100,000, several million.
Both in bandwidth and the servers actually managing it.
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..."
https://github.com/http2/http2-spec
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...
You are aware that ASCII and even more so UTF-8 is a binary protocol too?
They encode your bitmaps or vector graphic images into binary codes.
The codecs just so happen to be nearly automagically built into nearly everything.
I always wanted to see that been done to EMBL, so that you have a custom UTF-8 table that maps to tags instead of characters, and ebml uses the binary UTF-8 codes as tags. Any editor would simply decode/encode it to/from XML, and it would be just as transparent as UTF-8 or ASCII.
I totally misread that headline as saying HTTP 2.0 would be a Brony Protocol. And I was okay with that. At last, a functioning <rainbow_dash> tag. Support for Alicorn transformations. Working CSS elements (of Harmony). Yes, this would be a useful advance.
Genocide Man -- Life is funny. Death is funnier. Mass murder can be hilarious.
Unsolicited server push could be great to get status updates from the server to the client, but will probably only be used to force even more ads down your throat.
This is why humans read the protocol directly, instead of say, using a protocol analyzer software like wireshark,.... oh wait
I do both.
Sometimes it's nice to be able to do a 'telnet foo 80' or 'openssl s_client -connect foo:443'.
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.
A binary HTTP protocol would be a total loss. The Internet was built on easy-to-parse text, and languages like Perl. That was the magic that make it work, easy to manipulate and eyeball read text. Sure, you can write some sort of client to debug HTTP sessions, but you can't extend the web in ways no one ever though of before with a quick script - you have to write some low-level library to convert the stream first. Just an impediment to progress. Why not use VSAM files over HTTP for efficiency? Binary files have always been a total loss.
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 may be slow to parse and bloated, but that doesn't compare to the crap it's transporting. How many attempts at remote procedure calling does it host these days? Then there's the "too many connections" problem, because too few actually use keep-alive, and even if you solve that, these days that actually doesn't solve much of anything any longer, since too many hosts are involved to serve up even a single "thing". Such as trackers, ad servers, cdns, social button servers, social mugshot collection servers, maybe some static content servers, flash hosts, picture hosts, css generators, app support, javascript, possibly some data, the local pingback, what have you... and oh yes, maybe some actual content.
Just look how much data twitter.com serves up to show you one "tweet", a message of up to 140 characters, and alright, a username and a timestamp. Hint: It doesn't work at all without javascript enabled in your browser. But go ahead and count the total amount of traffic needed for just one such a thing.
Once we're beyond the facts of the whole thing being an unorganized jumble (the cloud in the cloud, if you will) needing to transport much, much more traffic than actual payload, there's that the formats used are widely disparate and... oh yes, slow to parse.
Of course, servers don't care for that part. Actually, yes they do, since they generally generate that on the fly these days. Using a variety of scripting languages, including this generation's platinum visual basic with diamonds on top, PHP.
So in the big picture, I have a hard time seeing how this will actually help much of anything. But hey, at least someone's trying, right? Just like the W3C keeps on trying to standardise, which in and of itself would be a rather spiffy idea. *sigh*
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.
Ironically the firewalls are put in to improve security... Perhaps we should be looking at other security mechanisms instead.
http://web.mit.edu/kerberos/firewalls.html
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
The using-multiple-connections approach was arguably a hack to get more bandwidth. SPDY (i.e. HTTP/2.0) fixes this. A single stream will go through the process of bandwidth sizing once. It should be more fair, not less.
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
Classic slashdot, can't even RTFA.
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.
maybe they should use this header:
Content-Encoding: gzip
http://en.wikipedia.org/wiki/HTTP_compression
why do we need a binary protocol to reduce network load when binary content transfers are already the norm?
binary protocol isn't going to make any difference, except create a huge migration overhead (good for creating jobs in the web dev industry i suppose)
applications that are bandwidth hungry (such as some games) likely already use their own binary protocols and won't ever change to any form of http
maybe they finally realized that most don't bother to RTFA anyway
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.
Multiplexing + binary protocol = multiple data read/write streams per port (any): near unlimited #'s in fact based on harmonics... riding the lighting on a wave of "subsonicsound" electrical signal &, thru all of its ranges. Not as good as we can do with fiber optics + light though. Man, that's got so much area/fill per (insert measurement stick here) more. Still, this has merit as a technology + data streaming methodology for some efficiency. That usually in turn translates out to speed. Speed usually is good. Overcoming your Objections - in that it's all really just signal @ diff. frequencies is all (lots of range here though). This sounds good for some speed, + efficiency though. That's always good. A better mixture of types of parts to purposes in an engine: Hotrodding commucations here really. Theory's good. Video data might be a good candidate: Stuff's heavy/Stuff's Streamable = good possibility of usage pairing for good bang for the buck in way less spent to get loads out of it efficiently. Probably already being done I imagine. I'd think that'd lend itself easily to that, in fact!
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! ;-)
They missed the most important part of a rationale for a new protocol.
The HTTP/2.0 protocol should include SSL and compression negotiation from the get-go at the transport level.
Everything could be compressed, including request, headers and content, no need to address them separately.
To make plain text requests you can choose null cypher which either server or client is free to reject.
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.
qwe
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.