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

Re: push_promise sent after frames that reference promised resources

From: Patrick McManus <pmcmanus@mozilla.com>
Date: Sun, 3 Nov 2013 16:09:38 -0500
Message-ID: <CAOdDvNqO-3g5wZJj7eQg09CW2S65AUhQBk39MhEwzKTsemj6Pw@mail.gmail.com>
To: Peter Lepeska <bizzbyster@gmail.com>
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, Martin Thomson <martin.thomson@gmail.com>
Every push is speculative and risks wasting a window of bw. To me this just
seems like a special case of that. Too much info asymetry to specify
behavior.

Just my thoughts.. See ya in yvr
 On Nov 3, 2013 2:41 PM, "Peter Lepeska" <bizzbyster@gmail.com> wrote:

> 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.
>>>>
>>>
>>>
>>
>
Received on Sunday, 3 November 2013 21:10:05 UTC

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