- From: Patrick McManus <pmcmanus@mozilla.com>
- Date: Sun, 3 Nov 2013 16:09:38 -0500
- To: Peter Lepeska <bizzbyster@gmail.com>
- Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, Martin Thomson <martin.thomson@gmail.com>
- Message-ID: <CAOdDvNqO-3g5wZJj7eQg09CW2S65AUhQBk39MhEwzKTsemj6Pw@mail.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