nitori

nitori OP wrote (edited )

Fun fact I still haven't done a Normal 1cc of a Windows 2hu except Touhou 19, but that one doesn't count because of the brokenly easy characters (like Reimu) coupled with the simpler requirement (compared to Touhou 3 or 9) to win a match there and a new mechanic where getting hit doesn't lead to losing health (unlike, again, TH03 or 09) but instead your "shield" disappearing (and if you get hit while in that vulnerable state then yeah you lose health) which you can regain by doing a level 3 or 4 attack

Meanwhile I've Normal 1cc'd Touhou 2 to 5. Touhou 1 is a different beast tho (it's not a vertically scrolling bullet hell at all but rather a weird hybrid of Arkanoid and bullet hell without the infamously tiny Reimu hitbox)

2

nitori OP wrote (edited )

Excellent write-up as always emma :D

I'm not much of a fan of ditching plain text for binary, since it makes debugging more complex (compared to 1.1 where you can just telnet lol), though I do realize that it's necessary if multiplexing is going to be a thing. Idk, is all of this added complexity really worth it just to shave off probably just the same as pipelining would do? In an ideal world where pipelining would only help the websites that really need it even with so many optimizations already applied and considered and where pipelining implementations in servers, clients, and proxies are perfect, I don't think so. But we don't live in that world, and frustratingly I suppose multiplexing is the way to go...

Idk I just wish that for every performance improvement we make, I can just be excited and not think about how webdevs are just going to ruin everything and add so much shit on top of the shit that became a non-factor due to those improvements that the improvements become meaningless again. Instead of "hmm how do we make the web go back to square one >:)" we just go "wow this is amazing we've reached peak I think :D"

Anyway I do wholeheartedly agree that pipelining is fundamentally wrong (even though it does work if it works), it just looks like a silly hack lol.

the server isn't required to support these

Oh, you can write a server that doesn't implement keepalive (while doing everything else 1.1) and still be 1.1-compliant? Well that's neat I suppose!

If virtual hosts didn't exist, I reckon we'd just see as much stuff shoved onto the same host as possible, and more extensive use of the path parameter in cookies to achieve the same stuff we have separate virtual hosts for in this reality.

This might be a cursed opinion but I do actually want all websites to be root/path-agnostic. So if you wanna host Postmill for example but you already have a separate service running in port 80/443, and can't do it in a separate domain (which would require another host in this reality) or port which would have its own root, then I should be able to put it in like /postmill instead.

Like think about it, CDNs like Cloudflare centralizing every damn website like we have right now wouldn't just be feasible without IPv6. Anycast is out of the question and each website under the CDN would require its own IP. The only way for this to go wrong is if every ISP just sold all of their address spaces to the CDNs and NATed the hell out of IPv4 that our own CG-NATs would sweat in fear of what we have created. But that's so ridiculous pessimistic imo that I don't think it will just happen. Well, hopefully.. :P

This exists because some http responses are produced before there's a known content length, thus the content-length header cannot be sent. It wouldn't be necessary if one connection handled a single request, though.

Oh yeah this is actually good lol, silly me :P

Looking into it more it seems like in HTTP/1.0 when there's no Content-Length, the client just assumes the transfer is successfully complete when the connection is closed. Which isn't good because we don't actually know whether the transfer was actually successful or it just got interrupted. 1.1's chonk stuff seems to be for that :D (EDIT: Actually maybe not but still neat regardless)

5

nitori OP wrote

I think TCP FO should be the way to go since it's more elegant imo than keeping a connection open, though unfortunately ossification means it will take a very long while to get all TCP-based services and clients to support it.. There's also privacy issues with its cookies

As for SSL, if we just had tcpcrypt or any other opportunistic encryption we wouldn't need Let's Encrypt or any free TLS lol (I feel like TLS has been abused too much, it should've been more about identity verification than encryption). I'm actually hopeful for Yggdrasil since it's an IPv6 mesh network where end-to-end encryption between IPs is the norm and each IP is a public key

4