W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013


From: Roberto Peon <grmocg@gmail.com>
Date: Thu, 21 Feb 2013 16:50:40 -0800
Message-ID: <CAP+FsNfkASsft5Za2EfbDwPmQ1S9gu1mop+6tCZTKHzQJ4a4bQ@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
Multiple people from the Google contingent (not just Will) are interested
in reprioritization and specifically allowing a 'client' (most likely a
proxy) to reprioritize pushed data.


On Thu, Feb 21, 2013 at 4:39 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> 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:51:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:10 UTC