Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTTP/2 Is Done

mnot.net

Post reply on HN
Print view View original

111–120 of 144 posts

Re: HTTP/2 Is Done

#111

Post by josteink »

TylerE wrote: post #110
bhouston wrote: post #100

Earlier quoted context omitted.

> HTTP/2 is all 100% mandatory. Any compliant HTTP/2 implementation will support an EXACT set of known features. But over the next couple of years, won't people come up with new ideas and add them as optional extensions? How is that handled? I suspect some of these optional extensions will be really useful in special cases such as support for LZMA/LZHAM compression in addition to just gzip.

There is support for extensions, but they're, well, extensions. The only thing the protocol specifies is that a compliant implementation must pass-through unchanged any block it doesn't understand. Compare with HTTP/1.1 where for instance the entire content negotiation mechanism is optional and clients need to be able to deal with it not being available.

> There is support for extensions, but they're, well, extensions.

So down the line, it will be pretty much exactly like HTTP 1.0 and 1.1 then.

Good to hear someone thought this thoroughly through before creating a mega-complex protocol unimplementable by most industry-grade engineers, which will also need to be debugged and maintained for all internet-eternity.

Re: HTTP/2 Is Done

#112

Post by lagg »

byuu wrote: post #65
bgentry wrote: post #16

It's time to begin the long process of unwinding all the hacks that we've built to make HTTP/1.1 fast. No more concatenation of static assets, no more domain sharding. The future looks more like this, as the default, with no special effort required: https://http2.golang.org/gophertiles May nobody else have to suffer through writing an interoperable HTTP/1.1 parser!

> May nobody else have to suffer through writing an interoperable HTTP/1.1 parser! Yes, now it'll be much easier than parsing plain-text. Now they just have to write a TLS stack (several key exchange algorithms; block ciphers; stream ciphers; and data integrity algorithms); then implement the new HPACK compression; then finally a new parser for the HTTP/2 headers themselves. Now instead of taking maybe one day to wri…

Thank you for saying this. I'm so fucking tired of the masturbation by and towards Google when it comes to this stuff. People are so used to reusing over-abstracted libs by large companies that they never think about the fact that they're both locking themselves in and actively harming robust standards (since a standard that only a few people can implement leads to only those people defining it. As is already happening here with Google).

I have a side project going on where I'm doing videos for people I'm mentoring to show them what lower level systems programming looks like. One of these videos was socket I/O where I fetched a page via HTTP in about 10 lines. I'll never be able to do something like this again in the near future. Yet people call HTTP2 "simple".

Re: HTTP/2 Is Done

#113

Post by viraptor »

josteink wrote: post #91
IgorPartola wrote: post #89

Earlier quoted context omitted.

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.

> 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…

> 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.

Re: HTTP/2 Is Done

#114

Post by al2o3cr »

hueving wrote: post #53
ecthiender wrote: post #32

Earlier quoted context omitted.

Excuse my ignorance, but how can I do session management without using cookies? I tried searching on the net, but it doesn't seem to give any concrete/valid results. Can you give me any pointers? Edit: I do use OAuth2.0 on my services and use Mozilla Persona to manage user logins, but I am not clear how can I keep sessions between requests if I don't use cookies.

You can carry the session ID in the URL. This also has the benefit of eliminating XSRF. The downside is that you have a horrendous URL if that type if thing bothers you, and you can't have a "remember me" check box in your login.

Partying like it's LITERALLY 1999...

Re: HTTP/2 Is Done

#115

Post by josteink »

mattmanser wrote: post #103
josteink wrote: post #93

Earlier quoted context omitted.

Think all software written for all devices involving every single embedded thingie with a webclient reporting in or polling data everywhere: Every ATM, every POS device, every IOT-device made yet and everyone to be made in the future. Every little gadget with a network stack ever made. And you're telling me all of those will have an updated HTTP-stack within 2 years? You're not being "overly optimistic", you're being…

You're missing the point. For all of them ut doesn't matter if my consumer website serves multiple assets. That's what I'm talking about.

Our point is that some people are treating this internet-protocol with a lifetime of decades like it was this week's update of Chrome.

It isn't. And it needs to be treated differently.

Re: HTTP/2 Is Done

#116

Post by MichaelGG »

stephenr wrote: post #82
omeid2 wrote: post #76

Earlier quoted context omitted.

Then we clearly have different definition of "application". For me, an web application runs in the browser, not merely exposes an API over HTTP that can be used by HTML from a browser.

You have a very narrow definition of an application then.

Yeah, him and every other user that includes basic features like "when I select the first step in a sequence of steps, the UI immediately responds instead of waiting several hundred ms to fetch an entirely new set of markup".

Every time I use Tor, I appreciate your viewpoint. But trying to pretend that most developers are better off spending their time maintaining a separate renderer for a few edge case users is not really reflective of reality.

Re: HTTP/2 Is Done

#117

Post by Practicality »

thomasfoster96 wrote: post #15

I know I'm apparently not meant to be, but I'm genuinely keen to start using HTTP/2. If you've been following some of the things being done in HTML recently (rel=subresource, rel=dns-prefetch), I think it's starting to become a little obvious that for most people HTTP is the bottleneck. HTTP/2 seems to be a good, solid step forwards. If it's not perfect, well, it doesn't have to be; 2 isn't the last number.

Agreed. I can't wait to start using it. Speed is a very important feature.

Re: HTTP/2 Is Done

#118

Post by spacecowboy_lon »

bhouston wrote: post #100
TylerE wrote: post #96

Earlier quoted context omitted.

Essentially, no. HTTP/1.1 contains tons of optional features. Practially no two implementations support the same set. HTTP/2 is all 100% mandatory. Any compliant HTTP/2 implementation will support an EXACT set of known features.

> HTTP/2 is all 100% mandatory. Any compliant HTTP/2 implementation will support an EXACT set of known features. But over the next couple of years, won't people come up with new ideas and add them as optional extensions? How is that handled? I suspect some of these optional extensions will be really useful in special cases such as support for LZMA/LZHAM compression in addition to just gzip.

Well in that case Apache Ngix Microsoft and the IETF need to keep control of the satndard any one that tries to add the http/2 equivelent of gets taken out and shot.

I have seen this before with OSI when MCI decided that part of the x.400 standard was optional. And not to mention ICL who thought that starting counting from 0 was a good idea when that standard said MUST START from 1 (and you wonder why the UK doesnt have a mainframe maker any more)

Re: HTTP/2 Is Done

#119

Post by MichaelGG »

marrs wrote: post #98
stephenr wrote: post #82

Earlier quoted context omitted.

You have a very narrow definition of an application then.

Absolutely. I'm sick and tired of idiot developers fucking up the web with their bullshit "apps" which are slow, crash all the time, and break everything. I've worked on more "web apps" than I can count and the reality is, only 2 of them were legitimate use cases for a pure JS solution. And we gain nothing from it. I've just spent all morning debugging an issue with a complicated angular directive (and not for the fi…

Even in 1999, using JavaScript to make far more usable UIs was common. While I'm not a fan of these bloated apps that need a couple megs of stuff just to render some basic looking page, let's not pretend that requiring user action and a full round trip to render even the smallest change was some golden era.

>that would have been a few lines of jquery a couple of years ago

Irony?

Re: HTTP/2 Is Done

#120

Post by rakoo »

josteink wrote: post #91
IgorPartola wrote: post #89

Earlier quoted context omitted.

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.

> 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…

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.

Post reply on HN