- From: Willy Tarreau <w@1wt.eu>
- Date: Fri, 18 Jul 2014 21:13:22 +0200
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: Jason Greene <jason.greene@redhat.com>, Michael Sweet <msweet@apple.com>, Nicholas Hurley <hurley@todesschaf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Hi Martin, On Fri, Jul 18, 2014 at 11:24:22AM -0700, Martin Thomson wrote: > On 18 July 2014 10:57, Jason Greene <jason.greene@redhat.com> wrote: > > It???s extra complexity, but the implementation isn???t difficult (a cake walk compared to other aspects of the spec). I can certainly appreciate the perspective from implementations that don???t want to touch their code though. > > I realize that this is a standard sophist technique in this forum, but > I find that selectively trivializing various aspects of the space > isn't particularly constructive. Let's try to be even-handed in our > analysis. > > On the one side: > > CONTINUATION has a cost in code complexity. It defers the discovery > of what might be a surprisingly large amount of state. > > On the other: > > A hard cap on size (i.e., option A) has a cost in code complexity. It > requires that encoders be prepared to double their state commitment so > that they can roll back their header table when the cap is hit. When > you consider compression, it does not prevent there from being a > surprisingly large quantity of header information. > > Option B seems almost orthogonal to these points, providing a 431 > warning. I'm not really certain how it would be used. > > Did I miss anything else pertinent to the discussion? Option B doesn't state that CONTINUATION are only used after a full header frame so it does not completely solve the issue. If it offered that provision, implementations could decide that upon receiving CONT they respond with a 431. That would discourage abusing CONT and sending too large headers (that would lead to the situation we have in 1.1 where interoperability is rather good overall). Willy
Received on Friday, 18 July 2014 19:13:53 UTC