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

Re: Implementation Notes on Server Push

From: James M Snell <jasnell@gmail.com>
Date: Tue, 14 May 2013 18:24:29 -0700
Message-ID: <CABP7RbftHeAQDiF7u8=nR-q0TVHYtHvSPUO+N48zJ=7Kj49fVQ@mail.gmail.com>
To: Roberto Peon <grmocg@gmail.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, Patrick McManus <pmcmanus@mozilla.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Tue, May 14, 2013 at 5:08 PM, Roberto Peon <grmocg@gmail.com> wrote:
> inline
>[snip]
>>
>> > There is language in the spec that if the client resets a stream that it
>> > implicitly resets any associated streams too. That was complicated to
>> > implement and pretty much broke my stream state model internally - while
>> > researching it it appears that mod_spdy and chrome don't implement it at
>> > all. The spec has an editorial note about removing that feature and I
>> > favor
>> > that removal.
>>
>> I added that text, so I tend to agree. :)
>
>
> I agree it should be removed. If we need a mechanism to close many streams,
> we can add a new opcode type instead of some implicit requirement.
>

If I recall correctly, everyone seemed to be nodding in agreement on this one.

>>
>>
>> > I found flow control for pushed streams immensely helpful. It lets the
>> > client bound how much data can be pushed before there is a local GET
>> > matched
>> > up with that. Relatedly, I changed my default SETTINGS window size from
>> > a
>> > ~infinite value to be a smaller push-apropos value and then pipelined a
>> > window update with each odd SYN_STREAM to make pulled streams ~infinite
>> > again while preserving the smaller limit for push and this worked fine
>> > with
>> > all existing servers to my pleasant surprise. That seems to mean at
>> > least
>> > the spdy/3 windowing mechanism is simple enough for people to get right.
>>
>> That's interesting.  Do you believe that it would be worthwhile
>> splitting the initial window size setting in two?  One for streams I
>> initiate, one for streams you initiate?  That would save you a window
>> update on every new stream.
>>

"Splitting the initial window" seems wrong to me. Of course, I don't
have a better suggestion at the moment, but if I did I'm not certain
it would be this ;-)

[snip]

- James
Received on Wednesday, 15 May 2013 01:25:15 UTC

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