- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Fri, 27 Jun 2014 09:55:46 -0700
- To: Jason Greene <jason.greene@redhat.com>
- Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
On 27 June 2014 08:22, Jason Greene <jason.greene@redhat.com> wrote: > The problem is the existing CONTINUATION mechanism is HOL blocking, which is particularly bad for proxies. This is absolutely true. The fix, as we've discussed in the past is to: a) not send CONTINUATION, or b) wait for the entire header block before forwarding at the proxy and reject anything that is detectably evil. The latter is a highly likely eventuality anyway, since certain critical routing fields are most likely to be found in the HPACK reference set, forcing the proxy to wait until the header block is complete before it can learn where to route the request (or whether to reject it). Primarily, I'm thinking about `:scheme`. Yes, there is a concern about how the proxy determines how much is too much, but we've pretty good general guidance from this community already: 8k or thereabouts is a pretty reasonable limit, though those with more diverse constituencies permit larger values. The reasons that I still favour the blocking nature of CONTINUATION are that it creates a strong disincentive to use it (see above), and it does simply processing in the unlikely even that you do need to handle it. CONTINUATIONS can be assembled (and streamed) at a layer just above framing, without having to invoke the rest of the state machine. Allowing for multiplexing would be optimizing for a case that we don't really want to support.
Received on Friday, 27 June 2014 16:56:13 UTC