15 ms·
>I would have liked to see an ascii based protocol I disagree I think HTTP should have been a simple binary protocol from the start and HTML should have requir
by voidlogic 13y ago
>I would have liked to see an ascii based protocol
I disagree I think HTTP should have been a simple binary protocol from the start and HTML should have required compilation into a binary format.
How much work would have it really been? htmlcmp foo.html providing foo.bhtml. No whitespace, No end tags, one or two byte tags, etc. Strictness in the reference HTML compiler implementation could have saved the web from all the stuff outside the actual standard that browsers (and other tooling) now have to support (so they don't "break" the web).
I'm not suggesting anything as crazy as the flash binary format (I wrote a Java flash player once...), but when I started to write things like proxy servers and HTML minifers I was blown away by the extreme inefficiency of HTTP/HTML.
This is a step in the "right" direction IMHO.
- samwillis 13y agoI believe that the "world wide web" took off for two reasons. It was completely free and it was incredibly easy for ANYONE to make a website. If you needed to "compile" all HTML it would have discouraged a lot of casual experimentation. Not everyone understands what a compiler is. Just as an example I started playing around with HTML when I was about 12 (in 1998), it was easy and I got instant results. A year or so later I tried to learn Perl and quickly gave up because I couldn't get my first script to run. It was another year before I tried to "program" again and became hooked. HTML and HTTP were successful because they were incredibly easy to understand. I wish we could keep it that way.
- voidlogic 13y ago>HTML and HTTP were successful because they were incredibly easy to understand. I wish we could keep it that way. The web is big enough today that we can afford to make it more efficient since we have so many professionals that don't require the kind of implicit hand-holding provided by the original implementations. Back then everyone was a newbie and there were no web professionals.
- samwillis 13y agoI think we need to be careful about claiming its more efficient. There seemed to be significant disagreement about how much more efficient SPDY was last year from the various different benchmarks. From memory the consensus seemed to be that its only 5-10% quicker. Does anyone have any more up to day benchmarks? I hate the idea that you would have to be a "web profesional" in order to get started today. We should embrace and keep the culture the web was built on.
- MrDOS 13y agoThat's an incredibly good way to lock out new newbies. I don't know how many people I know who got into programming through web development. Just because existing web developers don't necessarily need a simple solution doesn't mean new web developers couldn't take advantage of it.
- voidlogic 13y agoReally? I can't imagine anything they might do putting this out of the reach of say a sophomore C-S student or a motivated independent learner.
- nitrogen 13y agoA lot of current professionals started out as 11- and 12-year-olds dodging COPPA to host their first HTML web sites, not CS sophomores.
- voidlogic 13y ago>A lot of current professionals started out as 11- and 12-year-olds dodging COPPA to host their first HTML web sites, not CS sophomores. I would put those 11 and 12 year old down under "motivated independent learner" If your concern is the a binary HTTP, too bad, it already here, its called HTTPS. It does seem to be holding anyone back. If your concern is a binary HTML/compiler for it, I don't by that either. I was using a compiler when I was 8 years old and didn't have a problem with it conceptually.
- ajanuary 13y agoI'd argue the big thing that made HTML so easy to play with was permissiveness, not the lack of explicit compilation. Perl doesn't tend to have an explicit compilation step. You could write a HTML compiler to be as permissive as HTML parsers and you wouldn't have the same frustration you had trying to get started with perl.
- peterwwillis 13y agoGopher was simpler to understand than HTTP/HTML. But it wasn't as flexible, and didn't have as nice support for pretty pictures and midi files. If anything, HTTP/REST was much more complex. HTML was somewhat mystic yet allowed you to move things around easier, and actually design things vs just presenting them. And hyperlinks were really cool. http://www.ils.unc.edu/callee/gopherpaper.htm http://www.ils.unc.edu/callee/gopherpaper.htm
- weavejester 13y agoHTTP is a protocol designed to communicate information between two machines. There's no reason it should be human-readable. Trying to make a protocol that's easy for humans to read and write leads invariably means making it harder to write software for.
- dspeyer 13y agoA while back, I wrote a daemon that checked a bunch of network stuff in a loop. I needed a UI for it, so I made it speak http. No library, just raw GET support. It worked. Didn't take long to write, either. I would never have tried that with a binary protocol.
- nitrogen 13y agoI don't think anyone's saying HTTP/1.1 should go away.
- deleted 13y ago[deleted]
- weavejester 13y agoYou say that like you think a custom binary protocol would be harder than writing a HTTP server, even a simple one, from scratch.
- dspeyer 13y agoA custom binary protocol? Then I would have to write a client! And install it everywhere. And keep it updated. And design my gui in wingdi instead of html. That is not a viable option.
- weavejester 13y agoI thought you said you weren't using existing libraries? Or did you just mean for the server? You made it sound as if you thought writing a server for a custom binary protocol was harder than writing a HTTP server from scratch. If you're aiming for an existing ecosystem, then sure, there's no reason not to use HTTP, assuming you make use of established libraries. But widespread use is HTTP's only real virtue; the protocol is considerably more difficult to implement correctly than it should be.
- wtbob 13y agoWouldn't it have been cool if there were an efficient binary format and a nice human-readable and human-editable format, with a well-defined transformation from one to the other? Back in the 1990s, Ron Rivest came up with canonical S-expressions, which are fully capable of representing the same information represented by HTML, XML, ASN.1—but can be either human-readable or binary. Here's a simple example: (p (* class (footer x-treme)) "This is a " (b "footer") "."). Very human-readable, very human-editable, and easily machine-readable, wouldn't you agree? As a binary format, it would be (1:p(1:*5:class(6:footer7:x-treme))10:This is a (1:b6:footer)1:.). Still geek-manipulable, if necessary, and extraordinarily simple to parse. And it has the advantage that it is a distinguished encoding--any of the myriad human-readable encodings all reduce to the same canonical encoding, which has advantages for hashing.
- ANTSANTS 13y agoI see where you're coming from, I had a similar experience playing with HTML as a kid. That said, "compiling" HTML from text to an efficient binary format wouldn't have prevented browsers from including those compilers themselves and transparently compiling all plain text pages received. Newbies could keep on serving plain text HTML (until someone chastises them for it) while the web as a whole would benefit from the increased efficiency that comes from binary pages being the norm. Your argument doesn't really apply at all to HTTP, though. No one "got their start" peeking at HTTP requests. It's solely the domain of those working on infrastructure (for some definition of that word). Anyone with any idea of what HTTP really is (ie more than "that thing at the start of a URL") should have no problem using a tool to convert between a binary and text representation of the protocol. It's not like you can just magically pull HTTP requests out of the ether, you need a tool anyway. There's no reason why curl (for example) couldn't transform a request you write into an equivalent binary protocol, or why it couldn't do the inverse operation when it receives the response. It's utterly ridiculous to me that there is such inefficiency in HTTP just to make things slightly easier on the implementers of curl and wireshark.
- dangoor 13y agoDespite the "extreme inefficiency", HTTP/HTML have managed to work successfully for a very long period of time (and even worked decently well on very slow hardware in the '90s). There is actually a binary format that much of the web content is compiled into: gzip. It's remarkably effective. I will grant that following Postel's Law means that browsers have more work to do to ensure that all kinds of "busted" stuff on the web continues to work, but I'd guess that, at this stage, that work is pretty small compared to everything else browsers are trying to do.
- voidlogic 13y ago>here is actually a binary format that much of the web content is compiled into: gzip. It's remarkably effective. I'm sure you realize this but gzip is a content encoding. If there was a binary html format, it could still (and should be) gzipped (or better yet 7-zipped). I did some playing around this this and gzipped binary encoded HTML ended up around 1/4th the size a gzipped minified HTML. Gzip doesn't give you the other advantages of the hypothetical binary format, primarily: An extremely standardized and quickly parseable format.
- samwillis 13y agowhat "binary encoded html" did you use? I would be interested in seeing this as my initial thought would be that the both would gzip to almost exactly the same size?
- voidlogic 13y ago>what "binary encoded html" did you use? This was for internal testing, so it was a custom implementation. >my initial thought would be that the both would gzip to almost exactly the same size? That is like saying you would expect a gzipped CSV file to be as small as a gzipped database engine file. This of course not the case.
- jessaustin 13y agoSo which is which? Is html the csv or the DB dump? What is this metaphor even supposed to mean? It's not as though a csv file is sufficient to serialize a database. Actually, it would be more informative to point us at a "binary encoding", any binary encoding, that compresses smaller than the equivalent html text.
- specialist 13y agoHTTP should have been a simple binary protocol from the start What are the advantages of binary HTML vs plaintext HTML + gzip? I've observed many binary format efforts. Various binary XML, BSON, binary VRML. The only efforts that made any sense (penciled out) were binary geometry representations eg enabling mesh compression. (PS- I hate tagged formats like XML and HTML with the passion of a billion burning suns.)
- jakejake 13y agoCompiled binary HTML seems to me would be the end to the open nature of the web. The fact that anybody can view the HTML source is probably irrelevant from a network point of view. But I consider it a fundamental aspect of the web.
- voidlogic 13y agoHow would: hacker@gibson:~$ htmcmp ./myPage.html myPage.bhtml generated successfully. hacker@gibson:~$ htmdmp ./myPage.bhtml myPage.html dumped successfully. Hinder an open web? Maybe I am wrong, but my gut tells be this argument comes from developers who are not used to working with compiled languages. I think it would help new devs, can you imagine how nice it would be to have a handy HTML validator like this compiler would be? And how good for the web it would be to force everyone to use it? I can't imagine learning C without the feed back of a compiler and that was what I hated most about learning javascript and HTML. If you really hate the idea of having to run this compiler, it could be automatically run by apache, IIS, nginx, etc when serving your page for the first time. This is all hypothetical of course since such a standard does not exist.
- njharman 13y agoBecause the web took off cause non-developers, prot-developers were able to easily create pages, look at html/css/js and become developers. It seems trivial to you but having a compile step complicates things to beyond the reach of many. Plain text is more open and accessible than binary, full stop.
- LinaLauneBaer 13y agoYou could have embedded the compiler right in the browser. If you would open a html page it could have been automatically compiled and vice versa.
- lstamour 13y agoYou will still need and use plain text. File:// isn't powered by HTTP ;-)
- schrodinger 13y agoDoesnt GZipping HTML fix most of what you're complaining about?
- voidlogic 13y agoNo. There is more discussion in this thread, but for starters: 1. Gzipping doesn't make the HTML syntax that must be parsed by browsers more regular and efficient to parse. 2. Gzipped minified HTML is 4x as large as gzipped binary encoded HTML when I tested it.
- rjsw 13y agoThe "standard" way to have done this at the time would have been to use ASN.1, either on top of an OSI stack or used in a similar way to SNMP.