Re: idea -- MAX_PUSH_RESOURCE_SIZE

Server push can currently be disabled.
The amount of each resource sent can be controlled at a fine-grained level,
and so it can be throttled.

Server push currently enables cache validation/invalidation, as well as
offering a replacement for inlining.

What you propose would make it unreliable and thus un-useful for the
second. People would simply inline stead, destroying all of the potential
benefits.
It seems like a bad idea.
-=R


On Mon, Nov 4, 2013 at 1:07 PM, Peter Lepeska <bizzbyster@gmail.com> wrote:

> I understand that we want to minimize the config settings but this
> alternative solution has the much worse consequence of slowing down pushed
> resources in the 99% case when we expect the browser to actually use what
> we are pushing.
>
> If it is between no new config setting and starting with small per stream
> receive windows by default to limit the damage of unused pushed resources,
> I am fine with no new config setting.
>
> I think the receive windows should be configured to maximize performance
> and we should be very cautious any time we tweak them to deliver other
> functionality due to the possible side effect of slower transmissions.
>
> Isn't HTTP 2.0 supposed to primarily be about faster? We need to stick to
> that original goal!
>
> Peter
>
>
> On Mon, Nov 4, 2013 at 10:29 AM, William Chan (陈智昌) <willchan@chromium.org
> > wrote:
>
>> 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.
>>>
>>>
>>
>