Live data from Hacker News

HTTP/2 Is Done

mnot.net

131–140 of 144 posts

Re: HTTP/2 Is Done

#131
post #55

Stupid question: would you rather have server push serving static content from the application server or a CDN for the static assets? If a CDN, how can server push be leveraged when the assets are not related to each others (and the server can't tell in which order they will be requested).

That's really a very smart comment – no matter what happens with HTTP/2, things like geographic distance and failover are still going to matter and CDNs will still be important.

One key thing which should make this work is that server push should follow the same origin checks as most other recent web standards:

“All pushed resources are subject to the same-origin policy. As a result, the server cannot push arbitrary third-party content to the client; the server must be authoritative for the provided content.”

(http://chimera.labs.oreilly.com/books/1230000000545/ch12.htm...)

Assuming that survives contact with the actual implementations, you should be able to avoid latency-sensitive content going through the CDN while still being able to push out e.g. stylesheets & referenced fonts/images.

Re: HTTP/2 Is Done

#132

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…

> How about the average website?

It's actually much bigger for the average site which doesn't have Google's engineering team supporting hundreds of thousands of edge servers expensively pushed as close the client as possible and massive investment in front-end optimization. Think about how much complexity you can avoid taking on without needing to do things like sharding, spriting, JS bundling, etc.

Re: HTTP/2 Is Done

#133

Earlier quoted context omitted.

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

Because it doesn't solve any problems except page loading speed. There are other things that people care about and the added complexity of implementing Layer 4 in Layer 7 make it even more of a monstrosity. I put this in another comment in the above: * Better authentication * More secure caching * Improved ability to download large files * Better methods to find alternate downloads locations * Making each request con…

How is it that sensible comments like this keep getting downvoted?

Re: HTTP/2 Is Done

#134

Earlier quoted context omitted.

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

Double-digit performance for a bunch a little files probably. It is less than 5% when compared against concatenated CSS and JavaScript, image sprites, and domain sharding. Its great that HTTP2 saves a build step but it is hardly going to make the web a lot faster.

Re: HTTP/2 Is Done

#135

Earlier quoted context omitted.

Because it doesn't solve any problems except page loading speed. There are other things that people care about and the added complexity of implementing Layer 4 in Layer 7 make it even more of a monstrosity. I put this in another comment in the above: * Better authentication * More secure caching * Improved ability to download large files * Better methods to find alternate downloads locations * Making each request con…

How is it that sensible comments like this keep getting downvoted?

I just wish people would actually discuss their opposition to any statement I made rather than just downvoting, but so it is.

Re: HTTP/2 Is Done

#136

Another year, another wheel reinvented.

I know you're being somewhat facetious, but have you considered how much the wheel has actually been reinvented ? The first wheels were probably logs under rocks. Then axles got developed, then spokes, then tyres etc. Everything from the gyroscope to the LHC can attribute it's beginnings to the humble wheel. Reinvention is, if not always good, always admirable.

Up to a point, I agree. Beyond that point it becomes churn and reinvention for the sake of itself.

Re: HTTP/2 Is Done

#137

Earlier quoted context omitted.

Won't that create the same problems as XML and XHTML where full compliance is/was mandatory -- and the reality turned out to be different?

Probably not, most, if not all, non-compliant XML/XHTML is either written by hand or by very bad generation tools. In the case of HTML/2 it's a protocol that needs to be implemented by browsers and web servers and there are only so many of those. In the case of XML/XHTML any person throwing up a website or sending a document does the generation with a different set of tools(or by hand)

I've seen tons of computer-generated terrible xml. It's in use in so many custom API's I can't even describe to you. Poor escaping, nesting, &c.

Re: HTTP/2 Is Done

#138
post #65

Earlier quoted context omitted.

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

Have you tried writing anything more than a very simple HTTP/1.1 parser/server? It's actually not as easy as it seems at first - edge cases everywhere, different user agents doing subtly different things, etc. etc. Your argument is invalid in my opinion. HTTP/1.1 is not simple to implement to any decent level of completeness and correctness, and HTTP/2 does fix a fair few things. Anyway, there are already plenty of g…

HTTP/1.1 is only complicated if you want to support all of the optional features.

Re: HTTP/2 Is Done

#139

Earlier quoted context omitted.

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…

I didn't say JavaScript can't be used to ENHANCE an application, I'm saying it isn't necessary and apps should work without it.

Re: HTTP/2 Is Done

#140

Earlier quoted context omitted.

This is my real worry, at least nginx supports SPDY so has a base to evolve from, Apache support appears to be in a really bad place last time I checked.

The two most largely deployed servers on the Internet don't have HTTP2 support so their experience implementing and using it was never factored into the protocol. And people wonder why I don't like it.

MS seem to be doing a good job of building it into IIS, Traffic Server has it, as does H2O, nghttp2 and others.

Google, FB, Twitter, Akamai have adapted their http daemons for it.

nginx has SPDY support so HTTP/2 should be forthcoming but I wonder if this will be the death of Apache - they didn't seem to be able to update the SPDY plugin to 2.4

Post reply on HN