Subject: Non-browser uses (was Re: disabling header compression)

From: Martin Thomson <[email-masked]>
Date: Fri, 13 Dec 2013 11:27:52 -0800

On 13 December 2013 10:48, James M Snell <[email-masked]> wrote:
> On the question of adoption. Let me pose this question: what benefits,
> if any, does adoption of HTTP/2 offer to developers of HTTP-based
> RESTful APIs? What significant problems does HTTP/2 address that would
> justify the implementation costs? (Or is this another, "well they can
> just keep using HTTP/1" answer?)

I don't think that I'm alone in this, but the bulk of my day job at
Skype was building those sorts of systems with what you call "RESTful
APIs".  Having HTTP/2.0 was identified as a being hugely important to
the long term viability of those systems.  The primary feature there
was multiplexing (reducing HOL blocking is a big win), but we did also
identify compression as important (and potentially massively so).  We
were also speculatively interested in push for a couple of use cases.

---

From: James M Snell <[email-masked]>
Date: Fri, 13 Dec 2013 11:44:15 -0800

> were also speculatively interested in push for a couple of use cases.

Multiplexing is a win in *some* restful API cases; It is quite
dangerous in others. For APIs that rely on mixing sequences of
non-idempotent requests, multiplexing can be a major problem if
optimistic concurrency is not properly implemented, and even then
could cause significant problems if interdependent requests flow out
of order. I do agree that multiplexing helps significantly with APIs
with predominantly independent request flows.

Header compression, however, is at best a "nice to have". I'm all for
sending fewer bits down the wire, but the header compression mechanism
itself provides no direct benefit to the REST API developer who is
still required to deal with arcane, overly verbose header field value
formats, encoding schemes and ambiguities. The only benefit realized
at that level will be improved performance.

Any benefits Push may offer are, at this point in time, far too
speculative to be worth discussing.

My take away from your response is that, so far, the only benefit
HTTP/2 will have to offer RESTful API developers is improved
performance in some scenarios and fewer bits sent over the wire on
average. My question is: is that going to be enough to warrant broad
adoption among that group of developers?

- James

---

From: David Morris <[email-masked]>
Date: Fri, 13 Dec 2013 12:37:04 -0800 (PST)

> adoption among that group of developers?

I see the binary well defined data flow structure as a big win and w/o
header compression  or encryption to implement, quite possibly easier
to implement than http/1.x. Many of those developers will depend on
toolkits just like they do today. In that case, what becomes important
will be the processing burden on the device and perhaps debugging.

---

From: Nico Williams <[email-masked]>
Date: Fri, 13 Dec 2013 15:26:41 -0600

> with predominantly independent request flows.

It'd be nice to have an XID header like any multiplex-capable RPC
protocol.

Given just XIDs an application could determine incoming request
dependencies all by itself.  Explicit dependencies would be nicer but we
probably don't want to push ordering of incoming requests to the server
-- just the app is good enough.

> at that level will be improved performance.

It's enough.  But more than that, it'd be nice to commit to not doing
things that might make HTTP/2.0 bad for RESTful APIs.

> adoption among that group of developers?

Eventually, yes.  If for no other reason than that eventually there will
be servers that only serve HTTP/2.0.  That may be many years away.

Also, I could see adoption by APIs being swifter than adoption by
websites.

Nico
--

---

From: Daniel Stenberg <[email-masked]>
Date: Fri, 13 Dec 2013 22:50:20 +0100 (CET)

On Fri, 13 Dec 2013, James M Snell wrote:

> My take away from your response is that, so far, the only benefit HTTP/2 
> will have to offer RESTful API developers is improved performance in some 
> scenarios and fewer bits sent over the wire on average.

What about the convenience of running only HTTP/2 on your server and not have 
to manage legacy HTTP as well? I'd call that a benefit. Or possitive side- 
effect.

And I think better performance for your use case is a reason enough to use a 
protocol, even if that's not a browser.

> My question is: is that going to be enough to warrant broad adoption among 
> that group of developers?

I'm absolutely convinced that none of us here can KNOW the answer to that. 
With a solid protocol spec there will be HTTP/2 implementations written. If 
they are good enough and there are perceived benefits in using them, then the 
developers will use them.

I have such users in the curl community. I want to and plan to offer this 
ability to them.

-- 

  / daniel.haxx.se

---

From: Martin Thomson <[email-masked]>
Date: Fri, 13 Dec 2013 14:34:51 -0800

> with predominantly independent request flows.

... where *some* == most if not all.  If you assume that you are
talking about a single user context, then there are plenty of reasons
why you need to serialize requests.  I was talking about operating at
scale, with millions of users.  At that point, multiplexing is a huge
win.  When talking about thousands (or hundreds of thousands) of
requests per second, connection management in HTTP/1.1 is a major
cause of headaches.  Especially when there are a limited number of
peers involved (don't assume that all requests are terminated at user
agents, in these architectures servers make an order of magnitude more
requests than the final client.  HTTP/2.0 reduces overheads here
significantly.

> at that level will be improved performance.

When you are at the point that you are saturating links, a few bits
does make a difference.  We never measured any performance benefits
from the binary encoding, but it can't be worse.

> adoption among that group of developers?

So, you ask the question, then ignore my answer because clearly I
don't know what I'm talking about.

---

From: Howard Johnson <[email-masked]>
Date: Fri, 13 Dec 2013 14:57:16 -0800

At it's very core is not the current issue at hand:  just how to 
gracefully move from http1.1 to http2.0?  In other words, without a lot 
of time consuming negotiation on every request, as systems all over 
earth gradually adopt 2.0 and beyond.  And yes, we are trying to avoid 
something similar to the 1.1 gzip negotiation slowdown problem in the 
process.

I liken this to the transition from when we only had telephones (think 
http1.1) to when we email began (think http2.0).  How did we make that 
transition in communication protocols?

First we never got rid of telephones, they just got used less and 
differently.  (http1.1 will be here for awhile.)

As email started to appear (in our case http2.0) I remember that a lot 
of time was spent finding out if a particular friend (think: a server) 
had email or not.  Today the question is, does a site support http2.0 or 
not and with what features?

Now one could negotiate every single time we needed to communicate a 
message, in other words, first call by telephone and ask if the person 
had email, and if so send via email, but that's not what we did for it 
was too inefficient of a method of protocol transition.

Instead once we discovered a friend with email we noted that fact (kept 
a personal address list).  We also created public directories of who now 
had email.

I think this is how we should approach the transition from http1.1 to 
2.0, and from uncompressed headers to compressed headers, and other 
possible features, etc.  Provide the infrastructure to discover 2.0 
(both by negotiation and by public directory).  Let clients and servers 
use this cashe of information to decide how to most efficiently send 
http.  In other words negotiate once if need be, but then remember what 
the result was, and henceforth blindly send 2.0 and/or compressed 
headers to those we know can accept it.

Via this approach I think it will be in every bodies best interest to as 
quickly as possible adopt 2.0, just as we adopted email back in the day.

---

From: Chris Burdess <[email-masked]>
Date: Fri, 13 Dec 2013 23:58:29 +0000

> from the binary encoding, but it can't be worse.

True. Also the binary encoding has some as yet undefined flags that
could be used to select a type of compression of the header value,
allowing you to specify a compression algorithm best suited to the data
on a header-by-header basis.

---

From: Adrian Cole <[email-masked]>
Date: Sat, 14 Dec 2013 15:03:24 -0800

I am a developer who has been looking forward to http2 and helping support
it for non-browser clients via okhttp.

I gained interest through dealing with various cloud apis, some of which
restful, consumed through the apache jclouds and netflix denominator
projects I founded.  All of which could be helped by http2 directly or
indirectly.

Indirectly, one would hope both client and server sides will be more
scalable due to less tcp connections and efficiency within them.  Lack of
scalability has resulted in some cases with arbitrarily low, defensive api
quotas.  Imagine running amazon sqs.. http2 seems a nobrainer win for this
reason alone.

Also common is the cancelablity.  Programming constructs such as
Future.cancel or Subscription.unsubscribe are not effective in http1.
Basically you can nuke the socket.  GOAWAY is awesome.

If I had a nickel for every state polling loop... Imagine a HEAD push
promise to invalidate state (thanks jeff pinner for the idea).

What about inlining? How many rest api designs have inlined around
roundtripping concerns? Clearly, this is the same benefit to non-browsers
as browsers.

We also heard an interesting use case about prioritization for netflix
video traffic... that isn't really a browser concern.  I'm sure I have also
forgotten a bunch of other values, too ;)

Anyway, I am sure there will be doubt about the value of http2 for apis, or
concern that it can make bad developers worse.   I certainly would prefer
to give it a shot.  It makes too much sense not to.

As a part of this decision, I know I have to roll up sleeves and get
libraries and servers working.  Luckily, so are others, and moreso than
me.  Tooling and success stories will hopefully pave way to non-browser
developers innovating their stacks with http2.

-A