On Tue, Jul 1, 2014 at 7:38 PM, <K.Morgan@iaea.org> wrote: > > ***Is it worth continuing with this proposal?*** > > > > I think Michael brought up some really valid points. > > > > Assuming the following changes: > > + opcodes and their associated literal values MUST fit within the initial > HEADERS frame > > + opcodes and their associated literal values MAY span CONTINUATION frames > > + static table references are OK in CONTINUATION > > + same-stream muxing between HEADERS and CONTINUATION is disallowed > > + reference set emitted at the end of HEADERS/PUSH_PROMISE > > > > Does anyone thing this proposal is still worth pursuing? > Personally I prefer the current CONTINUATION spec to the proposed one. The proposed solution removes some restrictions, but introduces lots of complexities. And those complexities are just for "only 0.02% of requests and 0.006% of requests" in the world. I think it probably does not worth the cost. The servers always have the power to terminate connection if header size is too large for them. It is already a good incentive and pressure for peer not to abuse HEADERS, because large request will result in connection lost with higher probability. We already know headers > 16K (e.g., Kerberos), so we need CONTINUATION for them in anyway. Flow controlling CONTINUATION unfairly penalizes those valid HTTP requests by arbitrarily delaying transmission because of flow control and scheduling. In addition to this, as already discussed, headers are more likely kept in memory while reading entire request, so applying flow control for them just complicates both specification and implementation without good value. Best regards, Tatsuhiro Tsujikawa
Received on Tuesday, 1 July 2014 13:24:55 UTC