Yeah, this SGTM. One other point: The PR now expects the server to push only after it's heard a MAX_PUSH_ID from the client. Is it useful to still have the old boolean that would indicate push is disabled by the client? Otherwise you have a server that's waiting forever to push but can't because it didn't hear anything from the client "yet". (Tertiary point: it might be useful for various debugging/logging purposes to have an explicit disabling.) On Wed, Aug 9, 2017 at 5:36 PM, Martin Thomson <martin.thomson@gmail.com> wrote: > On 10 August 2017 at 10:20, Jana Iyengar <jri@google.com> wrote: > > I've assumed that without SETTINGS, you couldn't really send a request > > anyways, so that was basically necessary HoLB. This introduces another > frame > > that can cause additional HoLB. > > Right. Though I'm not sure that SETTINGS is actually blocking now > that it is so severely reduced in scope. It governs what you might > send in response, but only peripheral stuff, like header compression > table size, which are largely avoidable. But we already had that HOLB > problem for server push, so it isn't a major burden. If it is, then > sending the SETTINGS (or MAX_PUSH_ID) frame in every packet is a > possible, albeit crude, solution. > > I was going to make this argument: > > > Though you could easily make the argument that we'd expect SETTINGS and > the > > first MAX_PUSH_ID frame to be sent in the same packet. > > Especially since we just saved bytes from the SETTINGS frame. > > In any case, I've revised the PR. >
Received on Thursday, 10 August 2017 00:46:57 UTC