Re: push_promise sent after frames that reference promised resources

The main thing I'm trying to avoid is sending an object redundantly when it
doesn't need to be. And at the same time not require push_promises to be
sent before the frame that contains the reference to it.

Ideally we'd cancel the pulled request at the proxy because we know we've
already sent a prefetched (server pushed) copy of the same object. The HTTP
2.0 proxy could then inform the browser that the pulled request was
canceled via an error code that specifically indicates that the request was
redundant with a pushed resource. This would remove the need for the
RST_STREAM and eliminate the race.

If this is unclear I can describe what I'm suggesting in more detail.

Peter


On Sun, Nov 3, 2013 at 12:15 PM, Patrick McManus <pmcmanus@mozilla.com>wrote:

> either end can cancel any stream at any time. What is the specificinterop
> problem trying to be solved by proscribing exactly 1 stream to be rst and
> the other to be received? I'm not clear on that.
>
> consider the case where the flow control window for the latter pulled
> stream is already bigger than the window associated with the earlier pushed
> stream. The benefits of being earlier might well be wiped out by the rtt
> needed to open that window.
>
> Perhaps both streams are needed and none will be reset. (2 queries and a
> "cache" that is really just a ram fifo)
>
> -P
>
>
>
> On Sun, Nov 3, 2013 at 2:58 PM, Peter Lepeska <bizzbyster@gmail.com>wrote:
>
>> Proxies need consistency so they don't have to behave one way for one web
>> browser and another way for another web browser, much like the days when
>> IE6 incompatibilities required multiple implementations of web pages to
>> work across browsers.
>>
>> Peter
>>
>>
>> On Sun, Nov 3, 2013 at 10:00 AM, Martin Thomson <martin.thomson@gmail.com
>> > wrote:
>>
>>> On 3 November 2013 09:41, Peter Lepeska <bizzbyster@gmail.com> wrote:
>>> > Any reason this clarification shouldn't be incorporated into the spec?
>>> Seems
>>> > an important detail to the server push implementation that we'd want
>>> to make
>>> > consistent across all browsers.
>>>
>>> I don't see any real need for consistency there.  I'm sure that all
>>> the browsers will do what makes the most sense within the constraints
>>> of their architectures.
>>>
>>
>>
>