Plain text protocols

Yes, this is yet another web-based rant.
Why the fuck are we using plain text protocols such as HTTP?
Their fields are slower to parse, and this parsing is harder to implement, so what is the point beside some historical reason like "we don't have any utility to decode the headers so we read them ourselves?
Really, now that HTTP is used for literally everything, why not use a better, more optimized, protocol with less overhead.
It seems to me that most HTTP headers contain so little information that they can be condensed in no more than 64 bytes.

Because the maintainability of plain text over binary is worth wasting a few more nanoseconds of CPU time.

HTTP was obsoleted by SPDY/HTTP2 years ago. You fail

It's more about implementation than speed, though sometimes it's more than simply a few more nanoseconds.

Neither are used, HTTP 1.1 is the king everywhere.

Because everyone fell for the nginx meme :^)

To what end? Serious question. What benefits does switching away from a text-only protocol have in a non-real-time environment?

It's much easier to parse with low-level languages. I mean there's no reason to use text-based protocols in the first place.

There's plenty of use, because having a low-level, compiled language doesn't make sense for client-side scripting which is where a lot of this is managed. Even on the server, you're looking at a huge chunk of websites run on interpreted languages like PHP that abstract away raw streams, so it doesn't make sense to not have it be directly editable/readable/loggable by humans when the performance gains are minimal otherwise.

Putting that aside, if you're doing networking with a low-level language it should be in a library that abstracts all that away so you only have to think about it once (or never).

Computers got faster, so naturally we need more bloat. Seriously though, there is so much stuff that should be completely torn out and replaced so we can actually get the most out of modern day computers

...

Nothing wrong with HTTP being plaintext. I'd rather redo HTML/CSS/JS from scratch, but I know that if we did, corporate Jews would only create something worse.

Even if they do, for the few who adopt it it'll be like having our own little sekret club internet.

If a new set of web standards are made, I hope this time the design committee is more inclusive, specifically I would like to see Africa take a predominant role in writing the specification.

The internet is for all of us, why should it be decided by WHITE MALES?

Let's have a new intersectional web designed by LGBTQA/Feminists/POC/Islamists.

One bold idea really like is a packet-tax on anything sent out by rich western countries. With the packet-tax, we could use the resources to expand the web to impoverished nations whose voice needs to be heard.

Low quality bait, but....


Because we're the smartest. Real life is winner take all, and we're winners. Computer invented by? White male. Arpanet designed by? White male. WWW designed by? White males. First image shown over WWW? .gif of a white woman who a white male found hot. WWW is white white white. Don't like it? Go string some coconuts together and call it the BBB.

What? Holla Forums in my /tech? It's more likely than you think.

You recognize the bait, but then fall for it hook, line and sinker.

Because it was designed to be resilient to all forms of damage, even those that threaten civilization itself.

I think plain text is superior because it becomes language agnostic. This means that you don't need to know anything but a language and the HTTP protocol specification to implement a client.
It would be a pain in the ass to need codec libraries for HTTP binaries (or having to write your own), also, binary blobs fuck up protocol layering.
Having HTTP in plain text means you can optimize transfer in other layers like TCP.
You should also know that there are 4 fucking layers below HTTP adding overhead. HTTP resides in the session layer (OSI Model).


nginx 1.9.5 supports HTTP/2

Also, have you even implemented an HTTP server anyway? there is no complex parsing like a compiler or XML its way more like parsing commands from single lines back and forth, its so easy they let kids do it as homework.

Your rant is completely unfounded, you have no clue how things work and if parsing HTTP plain text is really hard to implement for you, it must mean you're a node.js cuck accustomed to being fed libraries to manage shit.

What are you even suggesting as an optimization? compression? its already done. transfer speed? bottlenecks on other layers should be fixed first as they add more overhead.
binary would just add a level of complexity completely unneeded for something as simple as a session layer application.

get good scrub.

Don't forget the Jewish contributions to computing.

Maintainability is infinitely worse with plain text, in current year + 1 people still avoid parser generators and parsing has a good 30 years of being the #1 cause of security holes. The reason it's used is it self-documents to a degree and doesn't become an opaque blob. Try comprehending old novell netware protocols. You have no chance. Now try with FTP.

we aren't 386 anymore. jesus christ.

Yeah. People are used to sanitizing strings now, but it seems like a ridiculous requirement when I think about it. If the parser requires this to be done, then maybe the parsing is bad.

nginx's http2 support is shit. It's just a buggy port of the http1.1 module, it supports absolutely none of the new features in http2 other than binary headers, and they've been fighting fires in it for the past 6 months. Apache did it right, and guess what? mod_h2 fucking works.

Sanitizing is the mark of a phppro. Where code mentioning sanitizing is found, security holes will also be found.

Shit battery life and lag is because you "muh cycles lol" webdev rejects have managed to make code require thousands of times more cycles to do the same thing.

Too bad apache doesn't work.

Gullible faggots like you are the kind of people who enable silicon megacorps to keep selling hardware that way too expensive for what it ends up doing.

Yeah sure thing faggot HTTP resides in the 9th layer out of 7 of the OSI model

Nigger, webdevs have nothing to do with that. The state of web development is entirely on the engineers who created the tools and the early adopters of those tools for adopting shitty tools.

Web development needs a hard reset.

Text protocols aren't that bad. Sure, with some languages operating on binary streams is piss easy, but some other languages are either very shit at it or require obscure lib/stdlib utilities to parse.

Meanwhile, 99% of non-esoteric languages have easy to access string utilities, often going as far as being languages designed around text processing. HTTP requests' syntaxes are easy enough to parse that only utterly irredeemable shit programmers can get it wrong without even using parser generators, so I doubt security is a valid reason to drop it.

HTTP requests are supposed to be key-value maps where keys can be arbitrary so it supports a really high degree of flexibility and extendibility. With binary requests this is not as easy (not that it can't be done, just that you either introduce plaintext key mode or standarize the shit out of everything).

What's with the hate of HTTP, anyway? It's the least cancerous, least resource intensive part of the entirety of the web ecosystem. HTML, CSS and JS each consume alone thousands of times the amount of superfluous cycles parsing the HTTP requires. "Muh cycles" is a valid complaint in O(n) functions, but only if you have already optimized that O(n^n) function that is consuming way more cycles than the first one.

Honestly, I don't know why nobody is angry at CSS making absolutely no sense from an architectural standpoint, or that HTML is unnecessarily complicated (both to code/generate and to generate parsers for), or at the fact that for being a language designed around DOM manipulation, JavaScript sucks at it so hard that it needs libraries to hide all that verbosity (you thought Java was verbose? Think again). Not only that, but every browser does stuff its own way so you need to tweak every single fucking aspect of your website for each browser to make sure it doesn't shit the bed, often having to program a different version of your stuff depending on the browser rendering it.

The web is a fucking nightmare and HTTP is the only thing that could be salvaged. Everything else must be thrown into the pit.

Not to say HTTP can't be improved by, for example, allowing the browser to request multiple resources in a single petition to reduce unnecessary extra requests, but come the fuck on.

IMO parsing something like ELF is way easier to do in C/C++ than plaintext. The problem is that it's the opposite in scripting languages... that and being self-documenting is also an advantage.

And? I don't see how this would be different with binary format. All this stuff is written in C anyway so it would be even easier to parse and stuff.

He is not wrong in that regard. Some people just consider the OSI model to be in the opposite direction, starting with Application and going down into Physical. Session layer would be the third layer, so you have four layers until Physical layer.

That said, I think we are talking about Application layer HTTP here, since the HTTP API (what HTTP requests are) are often put in this layer, but at the same time we are complaining about its Presentation since we are complaining about the format of a typical HTTP request. To be honest, I have no idea what type of "session" does HTTP provide since requests are generally stateless, so unless you consider a single request and a single reply a session, it shouldn't be put there.

tl;dr OSI model is retarded, unintuitive and only fun for Internet lawyering.

So when do we get started?

If he's talking about the overhead added by the physical, link, network and transport layer, I can't help but think he's a moron. The physical layer adds no overhead. The link layer adds no real overhead as it changes from node to node anyway. And the network and transport layer add what, 64 bytes of overhead?

What would it be more than just an AND to guess character width and detect surrogates?

actually it would be extremely complicated.
Imagine the following scenario: you start reading a UTF-8 string. You get a full word from the main memory (MM).
You read the first bytes: the first character is 3 bytes long. Okay. You process the first three bytes. Now you check the fourth and last byte you've loaded. The next character is 2 bytes long. So you have to shift your current word by 24 bits, then load another word, then remember you only have to process the highest 16 bits of the word you currently have in your register.

I see. That's still not that difficult. There's an instruction which does most of the work already (SHLD), and if you're proposing a fast way to read chunks of data from streams while reading in words, that would probably be better done as generic instructions for that purpose (so that compression algorithms could take advantage of it).

I think this is the first image on the WWW.

...

I wish they would account for Africa-tier speeds and hardware.