The HTTP crash course nobody asked for (opens in new tab)

HTTP/3 is written for the use case of large corporations and does not even allow for human persons to use it alone. It requires CA based TLS to set up a connection. So if you want to host a website visitable by a random person you've never communicated with before you have to get continued permission from an incorporated entity running a CA to do so.

This is far more of a security problem than all of the bad HTTP 1.1 implementations put together. It is built in corporate control that cannot be bypassed except by not using HTTP/3. It is extremely important that we not let the mega-corp browsers drop HTTP 1.1 and continue to write our own projects for it.

> whereas HTTP/1 is deceptively simple with therefore a lot of badly incorrect implementations

Doesn't that imply that HTTP/1 is deceptively complex?

I get what you're saying, but robustness through complexity feels like an odd argument nonetheless.

As someone who has not read the HTTP/1.1 spec, what are some pitfalls that could actually become security issues?

I don't think I could implement a correct HTTP 1 agent even if I read the specs.

But for back compatibility implementors will still have to support HTTP/1, which will likely take more than 50% of the total effort.

HTTP/2 makes no sense at all. HTTP/3 is just a fix to HTTP/2 so that it makes some sort of sense.

Both of these are only concerned with reducing the latency of doing lots of requests to the same server in parallel.

Which is only needed by web browsers and nothing else.

> How is WiFi so much more reliable than Bluetooth?

WiFi uses near 10x the power Bluetooth does when active (and that’s before factoring in BLE which cuts that down in half). WiFi also has access to the much less crowded 5GHz band.

IIRC WiFi is also a much simpler protocol, it’s just a data channel (its aim being to replace LAN cables).

Plus in order to support cheap and specialised devices Bluetooth supports all sorts of profiles and applications. This makes the devices simpler, and means all the configuration can be automated to pairing, but it makes the generic hosts a lot more complicated.

Bluetooth is massively more complicated than WiFi. It has a whole service enumeration/discovery layer baked in that IMHO tried to cram way too much into the spec. Whats even more amazing is that some of the hardware vendors at the table during the development went "F that" and added some side channel audio stuff that bypassing most of the stack.

But mostly the problem is that too much of this complexity fell on hardware vendors and they suck at writing software. There are umpteen bajillion different bluetooth stacks out there and they're all buggy in new and exciting ways. Interoperability testing is hugely neglected by most vendors. The times where Bluetooth works well are typically where the same vendor controls both ends of the link, like Airpods on an iPhone.

In 2020 I tried buying some reputable brand Bluetooth headphones for my kids so they could do home-schooling without disturbing each other. It was a total failure. Every time their computer went to sleep the bluetooth stack would become out of sync and attempts to reconnect would result in just "error connecting" messages, requiring you to fully delete the bluetooth device on the Windows side and redo the entire discovery/association/connection from scratch. The bluetooth stack on Windows would crash halfway through the association process about half of the time forcing you to reboot the computer to start over. Absolutely unusable. I tried the same headphones on a Linux host and they worked slightly better, but were still prone to getting out of sync and requiring a full "forget this device" and add it again cycle every few days for no apparent reason.

WiFi supposedly needs more power and has higher latency. Not sure how true that remains post WiFi6 though

HTTP Pipelining has the client sending multiple requests before receiving a response. It turns it into Request, Request, Request, Response, Response, Response.

The problem is that if Request number 1 leads to an error whereby the connection is closed, those latter two requests are discarded entirely. The client would have to retry request number two and three. If the server has already done work in parallel though, it can't send those last two responses because there is no way to specify that the response is for the second or third request.

The only way a server has to signal that it is in a bad state is to return 400 Bad Request and to close the connection because it can't keep parsing the original requests.

There is no support for HTTP pipelining in current browsers.

What you are thinking about is probably HTTP keep alive, where the same TCP/IP channel is used to send a follow-up request once a response to the original request has been received and processed. That is NOT HTTP pipelining.

> Isn't "HTTP pipelining" just normal usage of HTTP/1.1?

> Anyone that doesn't support this is broken. My own code definitely does not wait for responses before sending more requests, that's just basic usage of TCP.

Yep.

There is some "support" a server could do, in the form of processing multiple requests in parallel¹, e.g., if it gets two GET requests back to back, it could queue up the second GET's data in memory, or so. The responses still have to be streamed out in the order they came in, of course. Given how complex I imagine such an implementation would be, I'd expect that to be implemented almost never, though; if you're just doing a simple "read request from socket, process request, write response" loop, then like you say, pipelined requests aren't a problem: they're just buffered on the socket or in the read portion's buffers.

¹this seems fraught with peril. I doubt you'd want to parallelize anything that wasn't GET/HEAD for risk of side-effects happening in unexpected orders.

Not even just TCP, basic usage of message passing and any data flow.

Thanks, missed that.

Try https://fasterthanli.me/articles/a-half-hour-to-learn-rust which is also written by the same author.

You Tube Let's Get Rusty - ULTIMATE Rust Lang Tutorial! - Getting Started

Oh, this looks very promising. Thanks for the recommendation!

In OpenBSD nc (as GP mentioned), -c is for a TLS connection: https://man.openbsd.org/nc.1

My nc has that as -C, no -c option.

I'd like to thank you for the time and effort it must take to research, write and edit these articles. The tone you strike with these articles is a delight to read, and I find myself gobbling these things up even for topics about which I (falsely, it usually turns out) consider myself fairly knowledgeable.

Thanks for the link! Are there other good crash courses on various protocols and standards? Directly jumping into the dry official specs is just too overwhelmingly sometimes.

> kind of like the way the dimensions of the space shuttle booster are directly affected by the size of a pair of Roman war horses' asses.

I agree the two are similar, but the space shuttle story is also bullshit. See e.g. Snopes: https://www.snopes.com/fact-check/railroad-gauge-chariots/

People are suckers for plausible-sounding and amusing stories, that one's classic bait for people's lack of critical thinking skills.

> CRLF was used verily heavily and thus got baked into a lot of different places.

Well, exactly. Which is precisely why it's bullshit to claim that HTTP was "based on teletypes". It was based on technical standards at the time, that originally derived from teletypes, but there was no consideration of teletypes in the development of HTTP that I'm aware of:

> Many early web browsers were expected to be teletype machines [0].

Could you quote a relevant part of your reference? Because I don't see it. Perhaps you're confusing "dumb terminal" with "teletype"? Or confusing the Unix concept of tty, a teletype abstraction, with the electromechanical device known as a teletype - the "remote typewriters" mentioned in the original comment?

By the time that WWW spec was written in 1990, teletypes were decades out of date and not commonly used at all. PCs had existed for over a decade, and video display terminals for mainframes and minicomputers had been around for nearly three decades. No-one was using actual teletypes any more.

> So while it might be a bit of a stretch, I'd say this is far from "complete bullshit".

This conclusion would work if any of your claims had survived scrutiny.

HTTP is not “based on teletypes”. That’s just nerd hyperbole for a technical choice they don’t like, for irrational reasons.

The article covers using Wireshark to decrypt TLS traffic using Pre-Shared Master Secrets!

The encapsulation isn't complete because of SNI.