[byuu]

That would be absolutely lovely.

Since we're not viewing headers manually on 80x25 terminals anymore, we could do away with multi-line header values. That alone would drop off most of the complexity. (Being perfectly honest, even though it's part of the standard, you don't have to parse them now, anyway. I don't, and I've never had anyone complain to me about the site not working. Nothing mainstream sends them for the important fields.)

Add a Server-Push header (filename+ETag), and we could eliminate most extraneous 304 Not Modified requests. Have browsers actually acknowledge Connection: keep-alive instead of opening tons of parallel requests. And leave this as the "hobbyist level, can't afford wildcard SSL certs" option, and I think it'd be quite beneficial.

If browsers want to warn that it's not encrypted, fine. So long as they don't go into ridiculous hysteria levels like they do now with self-signed certs.

One immediate potential downside is Apache. It completely ignores the protocol request. If you ask for "GET / HTTP/1.2", or even "GET / HackerNewsTP/3.141e", it will happily reply with "HTTP/1.1 200 OK"

As a result, the negotiation would be trickier than with HTTP/2.

But like you said, it could be done in a way that it's 100% backward-compatible with existing 1.1 software, so long as their responses are also in a compatible, simplified format (and most already are.)

[viraptor]

> If browsers want to warn that it's not encrypted, fine. So long as they don't go into ridiculous hysteria levels like they do now with self-signed certs.

I don't believe they can do anything apart from what happens now. Imagine someone manages to redirect your traffic. You were talking to some website which used known certificate, but this time you got a self-signed one. The browser has two options essentially:

- continue the connection - in this case you just handed over your session cookie, the person on the other side can act as you on that website

- go into "ridiculous hysteria levels" and tell you that the cert presented by the server is not trusted - so do what browsers do right now

There's really no situation where the first option should be allowed. How option 2 is implemented is the interesting detail.

[IgorPartola]

I am with you up to letting people use unencrypted HTTP. I assume people in this can use telnet instead of ssh because it is simpler. No, browsers should drop support for unencrypted HTTP soon after Let's Encrypt goes live.

[josteink]

> browsers should drop support for unencrypted HTTP soon after Let's Encrypt goes live.

To the people who keep insisting everything needs encryption: No it doesn't. Fuck off!

You don't see me forcing PGP on on your email, do you? No? Fine, then let us non-weirdoes keep using plain HTTP where we want it, where we have determined that it is a good fit for our needs.

Besides, this is purely a theoretical concern because a browser which drops support for plain HTTP wont have any user-base as soon people discover that 95% of the internet will broken when using that browser.

[viraptor]

> You don't see me forcing PGP on on your email, do you?

Not pgp (as in, not end-to-end encryption). But hopefully in most cases you are forced to encrypt your email (smtp/tls), servers forwarding your email are likely using encryption (smtp/tls between servers), and you're pulling the email over encrypted channel (imaps). Alternatively your mail submission/collection goes over https to the email provider.

And yes, I will insist on everyone using encryption in mail, web, everything. Because once you actually want to use it for some reason, you don't want it to be completely different from all your other traffic, basically screaming "hey, I'm trying to hide some data here, because all my other connections are in plaintext".

Fortunately we're at the stage where everyone is actually forced to use encryption for a lot of their traffic.

[rakoo]

So, is the problem encryption or manual encryption ?

I presume you don't care about encryption when you send emails, and yet if you're using a big name your emails will be encrypted without you even knowing it.

That's why I keep wanting to put "automatic" encryption everywhere, and would rather have your browser demote plain HTTP as insecure as a TLS connection with RC4-MD5, and display good security connection with a higher "indicator" than those, even if the certificate is self-signed (yet not as high as a trusted communication)

In practice that would mean "this connection is PROBABLY secure. If you really care about what you're about to do, STOP NOW. If you don't care just go on".

"Automatic" PGP (or really E2E encryption) would be awesome, but there is still far too much manual work for it to happen. Maybe one day we'll be there.

[IgorPartola]

I assume you use telnet instead of ssh too. Once you do a little research and spend a little time figuring out what can actually be done (and is done constantly) to the unencrypted HTTP (anything from user tracking, to ad injections, to identity theft), you will realize just how wrong you are. Yes, HTTP needs to die. Sorry it's taking you a while to see it.