New approach to server push.

docs/asgi.rst

@@ -526,14 +526,32 @@ Server Push
 
 Must be sent before any Response or Response Chunk messages.
 
+When a server receives this message, it must treat the Request message in the
+``request`` field of the Server Push as though it were a new HTTP request being
+received from the network. A server may, if it chooses, apply all of its
+internal logic to handling this request (e.g. the server may want to try to
+satisfy the request from a cache). Regardless, if the server is unable to
+satisfy the request itself it must create a new ``http.response.?`` channel for
+the application to send the Response message on, fill that channel in on the
+``reply_channel`` field of the message, and then send the Request back to the
+application on the ``http.request`` channel.
+
+This approach limits the amount of knowledge the application has to have about
+pushed responses: they essentially appear to the application like a normal HTTP
+request, with the difference being that the application itself triggered the
+request.
+
+If the remote peer does not support server push, either because it's not a
+HTTP/2 peer or because SETTINGS_ENABLE_PUSH is set to 0, the server must do
+nothing in response to this message.
+
 Channel: ``http.response.?``
 
 Keys:
 
-* ``request``: A Request message. Both the ``body`` and ``body_channel`` fields
-  MUST be absent: bodies are not allowed on server-pushed requests. The
-  ``reply_channel`` set on this object will be used for all further messages
-  relating to the pushed response.
+* ``request``: A Request message. The ``body``, ``body_channel``, and
+  ``reply_channel`` fields MUST be absent: bodies are not allowed on
+  server-pushed requests, and applications should not create reply channels.
 
 
 WebSocket