> Where every line ends with \r\n, also known as CRLF, for Carriage Return + Line Feed, that's right, HTTP is based on teletypes, which are just remote typewriters
Does it need to be pointed out that this is complete bullshit?
The HTTP crash course nobody asked for
111–120 of 149 posts
Re: The HTTP crash course nobody asked for
#112> Where every line ends with \r\n, also known as CRLF, for Carriage Return + Line Feed, that's right, HTTP is based on teletypes, which are just remote typewriters Does it need to be pointed out that this is complete bullshit?
[deleted]
Re: The HTTP crash course nobody asked for
#113Earlier quoted context omitted.
> 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,…
HTTP pipelining is not normal usage of HTTP/1.1. And it means that if request number 1 fails, usually request number 2 and 3 are lost because servers will slam the door shut because of the lack of framing around HTTP it is too dangerous to try and continue parsing the HTTP requests that are incoming without potentially leading to a territory where they are parsing the incoming text stream wrong. This is what led to t…
There is clear request framing in HTTP/1.1, it's mandated by keep-alive.
Re: The HTTP crash course nobody asked for
#114Earlier quoted context omitted.
HTTP pipelining is not normal usage of HTTP/1.1. And it means that if request number 1 fails, usually request number 2 and 3 are lost because servers will slam the door shut because of the lack of framing around HTTP it is too dangerous to try and continue parsing the HTTP requests that are incoming without potentially leading to a territory where they are parsing the incoming text stream wrong. This is what led to t…
There is clear request framing in HTTP/1.1, it's mandated by keep-alive.
There is not, which is what leads to vulnerabilities where two HTTP protocol parsers will parse the same request in two different ways (which led to the HTTP desync attacks).
https://portswigger.net/research/http-desync-attacks-request...
There's a reason why web servers will slam the door shut even when the client requests HTTP Keep Alive because they are unable to properly parse a request in a way that makes it safe to parse a follow-up request on the same TCP/IP connection.
Re: The HTTP crash course nobody asked for
#115Amos' writing style is just so incredibly good. I don't know anyone else doing these very long-form, conversational style articles. Plus, you know, just an awesome dev who knows his stuff. Huge fan.
https://xeiaso.net/ is equally great content in a similar style in my opinion. Different area of topics a bit, but I enjoy both very much
Oh, this looks very promising. Thanks for the recommendation!
Re: The HTTP crash course nobody asked for
#116Earlier quoted context omitted.
Can you not just have it use a self signed certificate? I don't see why a CA would need to be involved at all, nor can I even imagine how that could be enforced at the protocol level. This sounds like a red herring to me. edit: Yeah I've more or less confirmed that self signed certs are perfectly fine in HTTP3. This is a big ball of nothing.
About half my personal (private, in my own home LAN) sites use self-signed certs that Chrome flat out won't accept. I have to type the magic key sequence to bypass the error. I do wish we could come up with something better for this kind of use case, then having to set up letsencrypt on my public domain and issue a wildcard cert to use with RFC1918 web sites. And that's without worrying about HTTP/3.
Add the certificate to your trusted store? HTTP3 will change nothing about this.
Re: The HTTP crash course nobody asked for
#117> Where every line ends with \r\n, also known as CRLF, for Carriage Return + Line Feed, that's right, HTTP is based on teletypes, which are just remote typewriters Does it need to be pointed out that this is complete bullshit?
Kind of.
Which part of it do you think is wrong?
Re: The HTTP crash course nobody asked for
#118Is there a way to get this guide without the annoying side-commentary?
The RFCs themselves are pretty dry, if that's your thing — https://httpwg.org/ has the freshest ones.
Re: The HTTP crash course nobody asked for
#119> Where every line ends with \r\n, also known as CRLF, for Carriage Return + Line Feed, that's right, HTTP is based on teletypes, which are just remote typewriters Does it need to be pointed out that this is complete bullshit?
Well, I've definitely seen a lot of people claim (generally not word-for-word) that using a pointlessly-overlong encoding of newline that exists to cater to the design deficiencies of hardware from the nineteen-sixties is not bullshit, so... maybe? But only for rather mushy values of "need".
Re: The HTTP crash course nobody asked for
#120Earlier 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…
Your complaint is strictly social, and quite irrelevant here. Look, cleartext internet protocols are on the way out, because their model is fundamentally broken. For security reasons, I will note, and privacy. There, we joust security against security. Cleartext HTTP/1 is strictly a legacy matter, retained only because there’s still too much content stuck on it. But browsers will be more aggressively phasing it out s…
>Look, be real: the entire web is now built heavily on the CA model.
No. You've just got your commercial blinders on. The entire *commercial web* is built on the CA model. But the commercial web is hardly all there is. There is a giant web of actual websites run by human persons out there that do not depend on CA TLS and who's use cases do not require dropping clear text connections. That's only a need for for-profit businesses and institutions.
I agree that the mega-corp browsers will drop support for any protocol that does not generate them profit. The consequences of this action will be dire for everyone. But you can't convince people of this. You just have to let it happen and let people learn from the pain. Just like with the social networks.