- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Thu, 21 Feb 2013 16:39:55 -0800
- To: Amos Jeffries <squid3@treenet.co.nz>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 21 February 2013 16:31, Amos Jeffries <squid3@treenet.co.nz> wrote: > When we start rationalizing server-push semantics so multiple replies can be > sent for one request. Most of the replies will need to be assigned some > lower priority than the requested reply - hopefully all within the one > stream. We will have to define a new response frame entirely to replace > reply. Why not just do it now and have initial implementations compatible > with those later ones? I don't get where you are going with this. It's already possible to send multiple replies for a single request. Each request gets its own stream. The server actually sends a SYN_STREAM for each extra "reply" (pushed resource). These streams are unidirectional. The client doesn't get to do anything to these streams, except reject them. With push promises, there is a push promise, followed by a later SYN_STREAM. Currently, the server chooses priority for pushed streams, but our Google friends (sorry I can't remember who specifically raised this, probably Will) are interested in reprioritising streams, which would allow a client to have a say about request priority.
Received on Friday, 22 February 2013 00:40:22 UTC