- From: Jason Greene <jason.greene@redhat.com>
- Date: Fri, 27 Jun 2014 10:22:54 -0500
- To: Mark Nottingham <mnot@mnot.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Jun 27, 2014, at 2:13 AM, Mark Nottingham <mnot@mnot.net> wrote:
> <https://github.com/http2/http2-spec/issues/541>
>
> Given where we are in the process, the widespread support for the current continuation mechanism, and the running code we already have, this is going to be a hard sell.
>
> From what I can tell, there are a few people who are proponents of this, but the support is relatively weak; I don't yet hear anything saying that this is a must-have.
>
> Please tell me if I've got that wrong.
The problem is the existing CONTINUATION mechanism is HOL blocking, which is particularly bad for proxies. Consider this topology:
+----+
|Evil+-----------+
+----+ h2 |
+---v---+
+----+ | | +------+
| C1 +-------> Proxy +-------------->Origin|
+----+ h2 | | Coalesced +------+
+---^---+ h2
+----+ |
| C2 +-----------+
+----+ h2
If “evil" sends large headers, which forces the proxy to send CONTINUATION, then the coalesced connection to origin unfairly favors Evil impacting the QOS for C1 and C2. Even worse is if Origin rejects and refuses to process the CONTINUATION, thereby requiring it to down the coalesced connection and forcing the proxy to reestablish. QOS suffers.
Mitigation options are for a proxy not to coalesce connections, which gives up a significant benefit of HTTP/2, or to reject big CONTINUATIONS from “Evil". The problem with the latter is the proxy has no idea what Origin can and can not handle.
The cost to fix this is minimal, and well worth eliminating HOL issues. Discouraging bloated headers is also a nice secondary benefit that many on this list have expressed interests in.
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
Received on Friday, 27 June 2014 15:23:25 UTC