- From: Greg Wilkins <gregw@intalio.com>
- Date: Fri, 11 Jul 2014 12:16:31 +1000
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAH_y2NHedfFm_mUUyaLwt=01pt4YcjTboJbippiavWFA3hbrWQ@mail.gmail.com>
OK, so keep the stream ID at 31 bits. I cannot see that similar arguments do not apply to length. There are already use-case for 64KB headers, so a 16b frame size is only just big enough for them today, so we have zero room for growth and there are some headers already larger than 64KB, so we are cutting off some users. I can't live with 16 bit length. 24 bit minimum for me. regards On 11 July 2014 11:54, Martin Thomson <martin.thomson@gmail.com> wrote: > On 10 July 2014 18:12, Greg Wilkins <gregw@intalio.com> wrote: > > 24 bits of each is still 16MB frames and 16M streams in a connection.... > I > > think both are reasonable guesses for infinity and this is a good > compromise > > between all the concerns. > > > We've had input to the effect that a rollover would occur too > frequently for some users at a 24-bit identifier. I think that the > number in question was a rollover every 10 minutes happens anyway. > I'd have to confirm whether that is at 31 or 24. Given how disruptive > a rollover is, a the extra bits are useful. > > Note also that stream identifiers are used elsewhere, so we'd need to > rework things in a few other places if they changed in size. > -- Greg Wilkins <gregw@intalio.com> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales http://www.webtide.com advice and support for jetty and cometd.
Received on Friday, 11 July 2014 02:17:00 UTC