This is gold.
The HTTP crash course nobody asked for
51–60 of 149 posts
Re: The HTTP crash course nobody asked for
#52> HTTP/1.1 is a delightfully simple protocol, if you ignore most of it. As someone who had to write a couple of proxy servers, I can't express how so sadly accurate it is.
I feel like this applies to many technologies. Made me think of the bootstrapping, “I-can-build-that-in-a-weekend” crowd.
The initial problem is usually easy to solve for, it’s all the edge cases and other details that makes something complex.
Re: The HTTP crash course nobody asked for
#53What a great overall site. Hopping down the links I found the section on files with code examples in JS, Rust and C, plus strace, really the best short explanation I've ever found online.
https://fasterthanli.me/series/reading-files-the-hard-way/pa...
Re: The HTTP crash course nobody asked for
#54> HTTP/1.1 is a delightfully simple protocol, if you ignore most of it. As someone who had to write a couple of proxy servers, I can't express how so sadly accurate it is.
And this is why I expect HTTP/2 and HTTP/3 to be much more robust in the long term: the implementations are harder to write, and you won’t get anywhere without reading at least a some spec, whereas HTTP/1 is deceptively simple with therefore a lot of badly incorrect implementations, often with corresponding security problems.
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.
Re: The HTTP crash course nobody asked for
#55That was an excellent, well-written, well-thought out, well presented, interesting, humorous, enjoyable read. Coincidentally I recently did a Rust crash course so it all made perfect sense - I am not an IT pro. Anyhows, thanks.
I'd like to ask you what crash course on Rust did you take, as there are quite a few out there, and it would help if someone recommends a certain course.
You Tube Let's Get Rusty - ULTIMATE Rust Lang Tutorial! - Getting Started
Re: The HTTP crash course nobody asked for
#56Earlier quoted context omitted.
> I feel like the author must know this The author does know this, it's a reference to a couple paragraphs above: > [...] and the HTTP protocol version, which is a fixed string which is always set to HTTP/1.1 and nothing else. > (cool bear) But what ab- > IT'S SET TO HTTP/1.1 AND NOTHING ELSE.
Thanks, missed that.
You know how some movie fans will sometimes pretend the sequels to some franchise don't exist? HTTP is the opposite.
Re: The HTTP crash course nobody asked for
#57Earlier quoted context omitted.
I'd like to ask you what crash course on Rust did you take, as there are quite a few out there, and it would help if someone recommends a certain course.
You Tube Let's Get Rusty - ULTIMATE Rust Lang Tutorial! - Getting Started
Re: The HTTP crash course nobody asked for
#58This is awesome, didn't read all of it yet, but I will for sure, I use HTTP way too much and too often to ignore some of these underlying concepts, and when I try to look it up, there's always way too much abstraction and the claims aren't proven to me with a simple example, and this article is full of simple examples. Thanks Amos!
Re: The HTTP crash course nobody asked for
#59Earlier quoted context omitted.
And this is why I expect HTTP/2 and HTTP/3 to be much more robust in the long term: the implementations are harder to write, and you won’t get anywhere without reading at least a some spec, whereas HTTP/1 is deceptively simple with therefore a lot of badly incorrect implementations, often with corresponding security problems.
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…
Is there anything the spec that actually requires that? AFAIK it's just that major implementators (browsers) have chosen to enforce TLS.
Re: The HTTP crash course nobody asked for
#60Earlier quoted context omitted.
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…
Is there anything the spec that actually requires that? AFAIK it's just that major implementators (browsers) have chosen to enforce TLS.
The language in the RFC that Google and Microsoft forced through the IETF to open-wash it uses "MUST" in capital letters when talking about setting up the HTTP3 endpoint and verifying the cert. https://datatracker.ietf.org/doc/rfc9114/
I would be extremely relieved if I am wrong and someone could explain how I am wrong. Like... maybe there's some mechanism to self-sign without CA and use a null cypher? So even if most users would be scared away geeks could click through (like today's status quo with self-signed ssl certs).