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 20:15:35 UTC