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

HTTP/2.0 Initial Draft Released

apiux.com

Post reply on HN
Print view View original

1–10 of 35 posts

Re: HTTP/2.0 Initial Draft Released

#2

Post by judofyr »

> Another new concept is the ability for either side to push data over an established connection. While the concept itself is hardly revolutionary — this is after all how TCP itself functions – bringing this capability to the widespread HTTP world will be no small improvement and may help marry the simplicity of an HTTP API with the fully-duplexed world of TCP. While this is also useful for a server-to-server internal APIs, this functionality will provide an alternative to web sockets, long polling, or simply repeated requests back to the server – the traditional three ways to emulate a server pushing live data in the web world.

As far as I know, this is not true. Server Push is only for the server and can only be done as a response to a request. It's not a WebSocket alternative.

Server Push means that when a client sends a request (GET /index.html), the server can respond with responses for multiple resources (e.g. /index.html, /style.css and /app.js can be sent). This means the client doesn't have to explicitly GET those resources which saves bandwidth and latency.

Re: HTTP/2.0 Initial Draft Released

#4

Post by ealexhudson »

cm3 wrote: post #3

Does http://tools.ietf.org/html/draft-ietf-httpbis-http2-04#secti... http://tools.ietf.org/html/draft-ietf-httpbis-http2-04#secti... and http://tools.ietf.org/html/draft-ietf-httpbis-http2-04#secti... mean sendfile(2) can't be used with HTTP/2.0?

Not entirely. You have TCP_CORK to allow headers to be stuck in front; sendfile can also take ranges so you don't blow the frame limits. I would imagine that kind of set up is more trouble than it's worth though (is sendfile(2) still the fastest way of doing things? I thought it had been superceded anyway...)

Re: HTTP/2.0 Initial Draft Released

#5

Post by jbverschoor »

judofyr wrote: post #2

> Another new concept is the ability for either side to push data over an established connection. While the concept itself is hardly revolutionary — this is after all how TCP itself functions – bringing this capability to the widespread HTTP world will be no small improvement and may help marry the simplicity of an HTTP API with the fully-duplexed world of TCP. While this is also useful for a server-to-server interna…

If that's the case, push is a bad name. Besides that, isn't this where multipart responses should come into play?

Re: HTTP/2.0 Initial Draft Released

#6

Post by inopinatus »

Why didn't they use SRV[1] records in DNS to resolve http2 requests? It has so many advantages:

  * Permitted at the domain apex (yes really! unlike CNAMEs!)
  * Allow weighted round-robin
  * Allows lower-priority fallback services
  * Unusual port numbers no longer required in URIs
  * Doesn't get confused with non-HTTP services located at the same FQDN.
It's the modern way to federate services! And there's very wide DNS server support - everything from BIND to Active Directory.

Fortunately the standard (nor as far as I can see, the normative references) doesn't actually say you have to use an A-type record. Unfortunately that will remain the convention unless someone makes this easy but explicit change.

I'd get involved but I fear the politics. Would I have any chance of being able to advocate for this change?

[1] http://en.wikipedia.org/wiki/SRV_record

Re: HTTP/2.0 Initial Draft Released

#8

Post by ablankst »

judofyr wrote: post #2

> Another new concept is the ability for either side to push data over an established connection. While the concept itself is hardly revolutionary — this is after all how TCP itself functions – bringing this capability to the widespread HTTP world will be no small improvement and may help marry the simplicity of an HTTP API with the fully-duplexed world of TCP. While this is also useful for a server-to-server interna…

If you check out the draft (http://tools.ietf.org/html/draft-ietf-httpbis-http2-04), it looks like either the client or the server is able to initiate and send data along the HTTP/2.0 streams.

And in Section 2.2:

>HTTP/2.0 provides the ability to multiplex multiple HTTP requests and responses onto a single connection. Multiple requests or responses can be sent concurrently on a connection using streams (Section 5).

This requires supporting client-initiated requests over an established connection.

Re: HTTP/2.0 Initial Draft Released

#9

Post by asm89 »

The draft was released earlier this month. There was an interesting discussion about it back then too: https://news.ycombinator.com/item?id=6012525

At the same time I also submitted another article that I still think is interesting and relevant as of today: https://news.ycombinator.com/item?id=6014976

Re: HTTP/2.0 Initial Draft Released

#10

Post by cm3 »

ealexhudson wrote: post #4
cm3 wrote: post #3

Does http://tools.ietf.org/html/draft-ietf-httpbis-http2-04#secti... http://tools.ietf.org/html/draft-ietf-httpbis-http2-04#secti... and http://tools.ietf.org/html/draft-ietf-httpbis-http2-04#secti... mean sendfile(2) can't be used with HTTP/2.0?

Not entirely. You have TCP_CORK to allow headers to be stuck in front; sendfile can also take ranges so you don't blow the frame limits. I would imagine that kind of set up is more trouble than it's worth though (is sendfile(2) still the fastest way of doing things? I thought it had been superceded anyway...)

You'd context switch to/from kernel way more often with small ranges. sendfile on Solaris, Linux, BSD and TransmitFile on Windows allow much larger ranges in one call.

What's the replacement for sendfile(2)? Solaris has sendfilev which is still pretty much the same thing and sendfile(2) on Linux uses splice(2), vmsplice(2), tee(2) internally but I don't know of a replacement.

Post reply on HN