Live data from Hacker News

HTTP/2 Is Done

mnot.net

31–40 of 144 posts

Re: HTTP/2 Is Done

#31
post #7

[placeholder for commentary about how HTTP/2 is a bad protocol because it's binary and everything could have been fixed in a text protocol follow by ad nauseum repetition of all the same old arguments]

The fact that there's so much disagreement and discontent surrounding this should concern everyone involved. Trade-offs are being made that may benefit some people and organizations, but these trade-offs are also causing significant problems for others. While there has always been some degree of disagreement regarding technological matters, I think we're really seeing a lot more of it these days, especially when it c…

We're repeatedly seeing a small number of people force their preferences upon increasingly larger masses of unwilling victims

This goes both ways though, doesn't it? Much of the arguing about HTTP/2 tended to be Johnny Come Latelies who, if we're being honest, seemed to just want to toss some refuse in the gears. Microsoft, in particular, watched as Google proposed SPDY, and then iterated and shared their findings, and then right as consensus (or as close to consensus as possible) starts to be reached, Microsoft tries to upset the cart. In that case wouldn't Microsoft, and the naysaysers, be the ones trying to force their preferences? The delay of HTTP/2, or basic improvements to these technologies, not only causes hassles for developers (image sprites, resource concatenation, many domains, and on and on), it marginalizes the web.

It is going to be pretty rare when any initiative sees complete unanimous agreement, especially given that many of the parties have ulterior motives and agendas that aren't always clear.

Re: HTTP/2 Is Done

#32

I wish instead of a protocol improvement that focused solely on network resources, the next version will also include improvements for users such as encryption by default and doing away with cookies.

You can begin today to do away with cookies on your own sites and services. Start implementing richer clients and leveraging Open ID Connect and OAuth2. Cookies solve real use case problems. Unless we all start building and experiencing and improving the alternatives, progress won't be made. That said, good luck on getting rid of cookies all together.

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.

Re: HTTP/2 Is Done

#33
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!

If anyone wants to learn more about optimizing for HTTP/2, unwinding HTTP/1.1 hacks, and strategies to optimize for both versions at the same time, Ilya Grigorik's "High Performance Browser Networking" is an excellent resource:

http://chimera.labs.oreilly.com/books/1230000000545/ch13.htm...

Re: HTTP/2 Is Done

#34

Earlier quoted context omitted.

You can begin today to do away with cookies on your own sites and services. Start implementing richer clients and leveraging Open ID Connect and OAuth2. Cookies solve real use case problems. Unless we all start building and experiencing and improving the alternatives, progress won't be made. That said, good luck on getting rid of cookies all together.

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.

HTML5 has local storage, so you can put auth tokens in there and only send them when you need them, versus on every request.

Re: HTTP/2 Is Done

#35
I read Daniel Stenberg's (he is a maintainer of curl, I think?) "http2 explained" pdf the other day, and it's by far the best comprehensive explanation of http2 that I have seen. Well worth a read if you're curious what's coming with http2. http://daniel.haxx.se/http2/

Re: HTTP/2 Is Done

#36

Earlier quoted context omitted.

Care to at least explain why you think it's a bad protocol?

It is not a bad protocol for what is in there, it is bad for what is not. It seems like it was built for the big players to eek out 5% more performance. How about the average website? What is in there help standardize authentication? What is in there to help protect privacy? In the end it looks more HTTP 1.2, with header compression being the only new feature. The rest of what makes up HTTP 2 is basically implementin…

On tests on a rather average SPA site I worked on, adding the letters "spdy" to the nginx config produced double-digit% performance benefits.

Keeping it backwards compatible with HTTP 1.1 as far as semantics means it will actually get real adoption, very easily, as you can seamlessly enable it via middleware without changing app code anywhere.

I don't know what you mean to "standardize auth", but seeing what a clusterfuck OAuth2 turned into, it'd probably guarantee HTTP2 wouldn't ship for a long time, then ship a mess.

To protect privacy, major browsers plan to only support HTTP2 over TLS. That should be a major incentive for more websites to force TLS. Pretty clever, sorta, even if we might have technical objections to requiring TLS for no "real" reason.

Re: HTTP/2 Is Done

#38

Earlier quoted context omitted.

The fact that there's so much disagreement and discontent surrounding this should concern everyone involved. Trade-offs are being made that may benefit some people and organizations, but these trade-offs are also causing significant problems for others. While there has always been some degree of disagreement regarding technological matters, I think we're really seeing a lot more of it these days, especially when it c…

> While there has always been some degree of disagreement regarding technological matters, I think we're really seeing a lot more of it these days I don't have any way to dispute this, but I don't think it's easy to provide evidence for it either. I feel that there may simply be more individuals involved in these kinds of discussions these days. Obviously at some point you have to stop discussing something and start…

Obviously at some point you have to stop discussing something and start building it.

No, see, that's where we are having problems: there is a perfectly valid answer of "It's good enough, or simple enough, that we will leave it as-is barring a really big leap".

Assuming that you've got to build something to replace the status quo is still itself an assumption. Saying, in effect, "Hey, we've got to build something" naturally disallows a reasonable engineering conservatism.

Software gets better not as you add things, but as you remove them--people keep forgetting this.

Re: HTTP/2 Is Done

#39

Earlier quoted context omitted.

This for example happened in the HTTP working group earlier today, the whole thing was rushed and the known flaws just keep adding up. https://lists.w3.org/Archives/Public/ietf-http-wg/2015JanMar...

I followed the thread a little further, and the response seemed reasonable: experiments were run on this idea, it didn't seem to help, and nobody (including phk) has offered any further evidence to the contrary since then. I think you need to expand a little more on why you feel this is a "known flaw".

A 60 page document to explain how to compress text name/value pairs that are mostly unchanged between requests is "reasonable"?

A static compression table with proxy authentication fields in it, as if the network between your browser and LAN proxy is somehow the bottleneck, is reasonable?

This is a most over-engineered protocol, one where nobody knows how tables were constructed or from what data and nobody can quantify what the benefits its features will really be. For instance how much is saved by using a huffman encoding instead of a simple LZ encoding or simple store/recall or not compressing it? Nobody knows! Google did some magic research in private and decided on the most complicated compression method, so therefore HTTP/2 must use it.

This HTTP/2 process is insane.

Re: HTTP/2 Is Done

#40

I wish instead of a protocol improvement that focused solely on network resources, the next version will also include improvements for users such as encryption by default and doing away with cookies.

It's unfortunate that TLS ended up being optional in HTTP/2, but if the big browsers only support HTTP/2 over TLS (as FF/Chrome have said they will do) then we might see very little non-TLS deployment.
Post reply on HN