W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: CONTINUATION proposal w/ minimum change

From: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Date: Tue, 1 Jul 2014 22:24:09 +0900
Message-ID: <CAPyZ6=+8y4Q41cAw_Y2fDoCw98ALUZAbG47+48nL5DJPjwnyrA@mail.gmail.com>
To: "K.Morgan@iaea.org" <K.Morgan@iaea.org>
Cc: Martin Thomson <martin.thomson@gmail.com>, Mark Nottingham <mnot@mnot.net>, phk@phk.freebsd.dk, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:08 UTC