On Mon, 4 May 2015, Ray Satiro via curl-library wrote:

> The advent of push and multiplexing could lead to a lot of resources being
> pushed. Resources that were once inline are no more; would-be same-origin
> resources that were once sparse on several servers are no more. The
> flexibility to handle push and stream priority/dependency will be crucial.

Yes, I too think that server push and HTTP/2 streams in general will only grow
in importance and popularity going forward. But we also don't need to invent
everything or fix every possible future problem now, we just need to lay the
foundation good enough and then we continue improving and polishing this. Like
we always do for all features.

> If I was contributing code to help implement this (it's not likely, sorry)

Don't worry about that! Right now, I think that contributing ideas and
thoughts around how it should or could work is equally or perhaps even more
important!

> I'd model to the maxim you don't pay for what you don't use. I'd disable
> server push by default and I'd expose SETTINGS_MAX_CONCURRENT_STREAMS for
> when it is enabled. I'm not saying you must know how many streams or only
> beforehand as in 1.

Yes. I've realized we need to have an idea of SETTINGS_MAX_CONCURRENT_STREAMS
is (and possibly even allow the application to extract it), so that we can
deal with the case when applications want more parallel transfers than so. I'm
actually working with exactly that scenario right now and the current
http2-multiplex code does not handle it very nice.

> I'm unclear on whether push stream DATA is sent immediately following the
> push of (promise) headers to the client or whether the client needs to give
> some explicit approval first. I'm guessing the former because of latency but
> really I don't know.

There's a SETTINGS_ENABLE_PUSH that can completely disable pushes for the
connection, but if we enable pushes they will come without any extra concent
as that is sort the point with them: no extra latency inferred.

We can also deny a new PUSH immediately if we don't want it - and that's what
we do right now actually. That's typically not a terribly large penalty.

> If push data starts on its own (and assuming that's not preventable via flow
> control setting) you'd need internally at least an object for each stream.

There's an initial window size of typically 64K, so a push can only send that
much data without our side explicitly telling the server that we have more
room for the stream.

> How about a new handle type curl_push_handle and make the easy handle
> options that do work backwards compatible so users can use their existing
> set_options functions.

Do you see any benefits in having them made as separate handle types rather
than regular CURL *handles with just some magic internal markers?

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html