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

71–80 of 144 posts

Re: HTTP/2 Is Done

#71

Post by sambe »

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…

I was under the impression that the parent was making the simplicity argument for people on the other side of things - people writing frameworks and websites. Using someone else's HTTP1.1 stack doesn't solve those problems.

Then, separately, writing interoperable HTTP 1.1 is hard because it was designed/taken up ad-hoc in a time of relatively immature browsers. I would expect HTTP2 to increase standardisation in the same way newer HTML/CSS specs have relative to the late-nineties. That doesn't mean that initial implementation will not be more difficult, but it's done once every 20 years (per-vendor).

Re: HTTP/2 Is Done

#72

Post by omeid2 »

stephenr wrote: post #48
MichaelGG wrote: post #34

Earlier quoted context omitted.

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

So rather than just using cookies effectively, you can make your application absolutely dependant on both JavaScrip and XHR?

"Applications" on the web are inherently dependant on JavaScript and most often XHR too, but I do agree that using Local Storage has little to no advantage over Cookies.

Re: HTTP/2 Is Done

#73

Post by stephenr »

omeid2 wrote: post #72
stephenr wrote: post #48

Earlier quoted context omitted.

So rather than just using cookies effectively, you can make your application absolutely dependant on both JavaScrip and XHR?

"Applications" on the web are inherently dependant on JavaScript and most often XHR too, but I do agree that using Local Storage has little to no advantage over Cookies.

> "Applications" on the web are inherently dependant on JavaScript

No, they are not.

Re: HTTP/2 Is Done

#74

Post by cm2187 »

youngtaff wrote: post #60
cm2187 wrote: 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).

Where sites serve the base page through a CDN, then the CDN has the potential to start making intelligent decisions on what should be pushed. As the simplest level this might be just the CSS, and JS in the but obviously as different UA's behave differently there's scope for much granular optimisations.

That's the easy, but relatively rare scenario. Today most content is dynamic.

Naively, it looks to me that server push will mostly be an improvement for small websites that do not use a CDN, but I can't see how it can coexist with a CDN.

Or it would require a new syntax, where the html tells the browser to start connecting to the CDN with this particular URL, which contains a token, and should be downloaded first which would tell the CDN that a particular list of assets will be needed for that page, and then the CDN will use server push to send these static assets.

Alternatively the CDN would become a proxy for the underlying html page, which would still be generated by the application server. That would probably be simpler.

Re: HTTP/2 Is Done

#75

Post by blueskin_ »

numbsafari wrote: post #22
tropicalmug wrote: post #21

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.

>richer clients

Please, no. The internet works because it's compatible, and installing a local client for everything just prevents use of a service.

Re: HTTP/2 Is Done

#76

Post by omeid2 »

stephenr wrote: post #73
omeid2 wrote: post #72

Earlier quoted context omitted.

"Applications" on the web are inherently dependant on JavaScript and most often XHR too, but I do agree that using Local Storage has little to no advantage over Cookies.

> "Applications" on the web are inherently dependant on JavaScript No, they are not.

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.

Re: HTTP/2 Is Done

#77

Post by byuu »

nyir wrote: post #68
byuu wrote: 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…

I haven't looked more into that, but wouldn't it also be viable now to start HTTP/1.2 with e.g. a more restrictive header grammar, restricting all existing features to what's actually used, at least on the server side? Clients with 1.1 support would keep working, but future clients would be simplified.

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

Re: HTTP/2 Is Done

#78

Post by MrBuddyCasino »

mattmanser wrote: post #64
derefr wrote: post #49

Earlier quoted context omitted.

The real problem, I think, will be moving to "idiomatic" HTTP2-centric design (lots of little resources, relying on parallel chunked delivery and server-suggested retrieval) while still keeping HTTP/1.1 clients fast. I'm betting there will come a polyfill to make HTTP/2 servers able to deliver content to HTTP/1.1-but-HTML5 web browsers in an HTTP/2-idiomatic way—perhaps, for example, delivering the originally-request…

Now that all of the browsers have moved to an auto update model and the only ones that haven't are on mobiles that have short lifespans, that's really only going to be important to the big players for about a year or two. Or maybe I'm overly optimistic!

I'm afraid you are - while things have improved for the reasons you outlined, corporate IT still going to be a major party pooper.

Re: HTTP/2 Is Done

#79

Post by scorpwarp23 »

I'd really like to know what this means in the context of MeteorJS - particularly how the HTTP Push feature will affect MeteorJS in the long run. Does it make MeteorJS redundant?

Re: HTTP/2 Is Done

#80

Post by scorpwarp23 »

I'd really like to know what this means in the context of MeteorJS - particularly how the HTTP Push feature will affect MeteorJS in the long run. Does it make MeteorJS redundant?
Post reply on HN