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

Re: idea -- MAX_PUSH_RESOURCE_SIZE

From: (wrong string) 陈智昌 <willchan@chromium.org>
Date: Mon, 4 Nov 2013 10:29:10 -0800
Message-ID: <CAA4WUYhdWTd9pyYNqVvBpr4jNnUFwODmdnLX4P1DJP2Kh1sb=A@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Peter Lepeska <bizzbyster@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Note that the FF strategy (which we've discussed Chromium side) is to start
with smaller per-stream receive windows by default, and upgrade them
immediately for normal streams, or as Pat calls them, "pull" streams. This
would let stuff like push streams, or as Chromium is discussing, web
platform prefetch/prerender/etc streams, start with smaller receive windows.


On Mon, Nov 4, 2013 at 10:14 AM, Martin Thomson <martin.thomson@gmail.com>wrote:

> On 4 November 2013 10:00, Peter Lepeska <bizzbyster@gmail.com> wrote:
> > As per above, the browser currently can only set max concurrent streams
> to
> > limit the amount of data pushed to it but perhaps better is to set a max
> > size of file that the browser is willing to accept via server push.
>
> We are, as much as possible, attempting to limit the number of
> settings that we allow in the protocol.  I take that to mean that
> there needs to be a high bar on the addition of settings.
> Specifically, if there is an alternative solution to the problem, then
> it's not enough.
>
> In this case, if you are concerned about the size, the flow control
> window will allow you to control the size and give you time to
> generate RST_STREAM as appropriate.  ...Trade off as appropriate
> against your desire to maximize throughput.
>
>
Received on Monday, 4 November 2013 18:29:37 UTC

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