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
