Does HTTP2 support multiple concurrent streams over a single client connection? If not, presumably your use case would require that the client has a separate HTTP2 connection opened up to the CDN already, right? Or am I missing something?
To me, I would say increasing efficiency (or decreasing latency) was a central design goal of HTTP2. So HTTP2 includes it's own framing, which allows multiplexing across the connection. This helps avoid the overhead of establishing multiple parallel connections to speed up page load, head of line blocking, running slow start on each connection, etc.
FWIW the use case I'm describing has already been added to Rails / Puma:
http://eileencodes.com/posts/http2-early-hints/
While the RFC does state that what you described can happen at a caching intermediary, I don't believe that's where the value lies or the primary use case. To me, much of the value added is to get the 103 to the client early, and allow it to begin making decisions on whether the content is in it's local cache, or to begin making requests to third party servers.
This helps eliminate some of the weaknesses with HTTP push, mainly being that only content the server is authoritative for can be pushed, and that the server doesn't know whether the resource to be pushed already exists in a client cache.
It's a balancing act of course, but if the resource being pushed is above a certain size, pushing the resource on each request could add overhead, not reduce it.
> This helps eliminate some of the weaknesses with HTTP push, mainly being that only content the server is authoritative for can be pushed, and that the server doesn't know whether the resource to be pushed already exists in a client cache.
When a server sends a push to the client it first sends `PUSH_PROMISE` command to the client and the client may cancel the push, e.g. if it already has the asset in cache based on url. Assuming things move forward the server sends a HEADERS frame which can also trigger to the client to cancel the push, e.g. in response to an etag, though at this point some DATA frames may be in flight.
You are correct that you can't push assets for another domain, but I don't see this as much of a problem as there are many other benefits to having all requests go a CDN/reverse proxy that can handle the static asset serving, like regional SSL termination. There are of course third party scripts that may be needed, but it's good practice make these non-blocking for page rendering anyway so if they are a bit behind that is probably ok, if not preferable.