Re: push_promise sent after frames that reference promised resources

Hi Mike,

Thanks for the good discussion - so much more efficient in person.

"Given that in your scenario there’s almost zero latency between the client
and the proxy, it might make sense to *never* pass a push to the client and
just let the server’s pushes fill your cache.  You can then fulfill client
requests from cache immediately."

For the sake of not causing confusion on the list, I'd rather not go into
the specifics of the satellite two part proxy that I work on. After all,
one of the reasons I'm so excited about HTTP 2.0 is so I can push directly
to the browser.

Peter


On Mon, Nov 4, 2013 at 3:52 PM, Mike Bishop <Michael.Bishop@microsoft.com>wrote:

>  Continuing our conversation on push here….  I’m the one who pushed for
> SHOULD rather than MUST.  Because I own a component which sits between the
> application telling us to push and the wire, I can’t comply with a MUST
> without inspecting and interpreting the HTML and headers being sent by the
> app calling me.  It’s a SHOULD because non-compliance is dumb and wasteful,
> but not an interoperability issue.
>
>  As for the advantage or lack thereof to a proxy, the proxy should be
> doing its own pushes or receipt of pushes.  Given that in your scenario
> there’s almost zero latency between the client and the proxy, it might make
> sense to *never* pass a push to the client and just let the server’s
> pushes fill your cache.  You can then fulfill client requests from cache
> immediately.
>
>  You can’t “kill” the request, because you might mess up the browser’s
> state.  If you already pushed a copy, you clearly have it at the proxy, so
> just satisfy the request from cache again without passing it to the server.
>
>  Sent from Windows Mail
>
>   *From:* Patrick McManus <pmcmanus@mozilla.com>
> *Sent:* Sunday, November 3, 2013 1:12 PM
> *To:* Peter Lepeska <bizzbyster@gmail.com>
> *Cc:* HTTP Working 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.
>>>>>
>>>>
>>>>
>>>
>>