Re: push_promise sent after frames that reference promised resources

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<mailto:pmcmanus@mozilla.com>
Sent: ?Sunday?, ?November? ?3?, ?2013 ?1?:?12? ?PM
To: Peter Lepeska<mailto:bizzbyster@gmail.com>
Cc: HTTP Working Group<mailto:ietf-http-wg@w3.org>, Martin Thomson<mailto: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<mailto: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<mailto: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<mailto: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<mailto:martin.thomson@gmail.com>> wrote:
On 3 November 2013 09:41, Peter Lepeska <bizzbyster@gmail.com<mailto: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.