141–149 of 149 posts
As far as i can tell the host header is pointless, because if it's ssl/tls you won't be able to read it and route it. That's what sni is for. If you aren't tls then you don't need it, unless you hit the server as an ip. But then why would you do that?
Is HTTP always the same protocol as HTTPS - given the same version - and ignoring the encryption from TLS? Theoretically yes, but in practice? I've done my share of nc testing even simpler protocols than HTTP/1.1 For some reason the migration to HTTPS scared me despite the security assurances. I could not see anything useful in wireshark anymore. I now had to trust one more layer of abstraction.
Earlier 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…
Earlier quoted context omitted.
The link shows how to exploit certain bugs in some bad implementations. That doesn't change the fact the protocol itself is quite well-defined. There is no serious HTTP server that wouldn't support keep-alive, this is just FUD.
You are conflating keep alive with http pipelining, they are not one and the same. Keep alive may be supported and servers may claim to have fully parses request 1 correctly so they can be fairly confident request 2 can be parsed correctly, but reading the spec one way or another and that is no longer a guarantee that holds. Keep alive and http pipelining are supported by major servers, some with bugs or issues, but…
Pipelining is just normal usage of TCP, which is a mechanism to establish two queues of bytes between two endpoints on a network.
There is no difference between sending data before or after having received data from the other party. The two directions are logically independent, even if at the transport level data from one direction contains acks of the other direction.
Now, some servers will start processing requests on a given connection in parallel, and will not correctly synchronize the multiple threads trying to write back their respective response to the client. This is just a bug on the server doing multithreading incorrectly, and has nothing to do with any framing problems in the protocol.
I suppose HTTP/2 supports that use case better, since it can multiplex the concurrent responses, but the correct thing to do is to simply treat each request synchronously one after the other, and not parallelize the processing of multiple requests on a given TCP connection.
Earlier quoted context omitted.
> 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 think the idea is that HTTP/1 is simple in the hello-world 5th-percentile-complexity case, which deceives people into thinking that it's also simple in the real-world 99.9th-percentile-complexity case, which it's not at all.
And a decent HTTP-proxy must handle all of that stuff or at least fail gracefully without affecting other clients.
> 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?
CRLF was used verily heavily and thus got baked into a lot of different places. Namely, it conveniently sidesteps the ambiguity of "some systems use CR, others use LF" by just putting both in, and since they are whitespace, there's not much downside other than the extra byte.
Beyond that, there are many other clear and obvious connections between Hypertext Transfer Protocol and teletype machines. Many early web browsers were expected to be teletype machines [0]. So while it might be a bit of a stretch, I'd say this is far from "complete bullshit".
[0] - http://info.cern.ch/hypertext/WWW/Proposal.html#:~:text=it%2...
More articles should be written in the style of this article. Thank you for this.
> 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?
> 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?
It's not totally right , but it's not totally wrong , either, 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. CRLF was used verily heavily and thus got baked into a lot of different places. Namely, it conveniently sidesteps the ambiguity of "some systems use CR, others use LF" by just putting both in, and since they are whitespac…
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.