undefined

points

[-]

We don't need new versions of http or SMTP because they're already simple and great and they're dumb protocols so there's not much you could ever add

If you want something else you can take your pick based on need from dozens of other options

by cowlevel21 hours ago|

parent|

[-]

HTTP 1 is full of parser differential vulnerabilities, which 2 fixes. That is probably its biggest flaw.

SMTP is too chatty - it uses too many round trips for efficient transfer across the internet. It can take several seconds just to get to the point of sending the email data. It also duplicates information between the SMTP envelope and the email body which creates vulnerabilities when they don't match.

For APIs that don't have to work in a browser I suggest JSON lines over TCP, or over TLS.

by rfgplk21 hours ago|

parent|

[-]

Most header parsing bugs that affect HTTP1.1 can also affect 2+3. Not in the same style but there are quite a few overlapping ones.

by cowlevel17 hours ago|

parent|

[-]

Only when 2/3 translates to 1, as in request smuggling attacks at a reverse proxy.

by cowlevel21 hours ago|

prev|

[-]

"by default its a new socket for each message" is misinformation - keepalive is the default since HTTP 1.1 (1999).

by austin-cheney18 hours ago|

parent|

[-]

Keep alive is not default behavior, so my prior comment was still more correct.

by tredre317 hours ago|

parent|

[-]

All webservers (apache, nginx, litespeed, caddy) have keep-alive enabled by default. All browsers also support it. Whether it's actually used/negotiated on most connections, I don't know, and if you want to be pedantic you're right that it can't be default by definition since you need the header to use it. But I suspect it actually is used for most connections nowadays.

Multiplexing is the default in HTTP/2 and 3. So you're still wrong.

by austin-cheney15 hours ago|

parent|

[-]

https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...

https://stackoverflow.com/questions/36517829/what-does-multi...

So, for the sake of argument let’s say I am completely wrong, MDN is wrong, all of Stack Overflow is also wrong. Even still HTTP is slow. Slow as shit. Imagine trying to do a MS Teams call with 50+ participants with cameras on. It would be slow as shit for just a one-on-one call. A call with 50+ people would be ridiculously slower and would likely result in a crash from memory exhaustion.

I was also not talking about HTTP2 or 3. I was very clear about that. Reading is hard. HTTP is used in many different contexts outside the browser where 1.1 continues to dominate.

The primary reason developers want to keep HTTP around is familiarity and comfort. HTTP is great when you don’t compare to anything else or do any kind of performance tuning.

by cowlevel17 hours ago|

parent|

prev|

[-]

Keepalive is literally the default. You have to send an additional header if you don't want to use keepalive.

by rfgplk21 hours ago|

prev|

[-]

Agreed. The issue with all these archaic standards is that they were rolled decades ago back when certain practices were either outright not being employed OR that hardware wasn't fast enough. Ironically, HTTP itself is a literal nightmare to parse (performance wise) on top of having like... ten? distinct vulnerability classes. The world desperately needs new standards.

by cowlevel21 hours ago|

parent|

[-]

Just open a TCP socket and send JSON messages. Or if you want a bit more efficiency, fixed-format binary messages, but remember to include a version number.

by rfgplk21 hours ago|

parent|

[-]

For custom server implementations, agreed. But the web still depends on HTTP and we sadly need the major infra providers to agree on a new standard otherwise HTTP isn't going anywhere

by cowlevel17 hours ago|

parent|

[-]

Web uses web protocols, notweb uses notweb protocols. When I write an XMPP bot it has to speak XMPP, not HTTP. I could write my video game server to use XMPP but why the heck would I do that? If I choose a badly fitting protocol, it's on me.

by graemep16 hours ago|

parent|

[-]

I think one problem there is that a lot of places block other ports. Was that not why websockets runs on http ports?

by cowlevel10 hours ago|

parent|

[-]

Websockets have to be careful not to enable a client-side SSRF by accessing anything you couldn't already access with an <img> tag. They can use any port except the ones that are generally prohibited for browser HTTP requests, such as 25 and 6667.