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

Re: #541: Stateless Multiplexable Continuations

From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 27 Jun 2014 09:55:46 -0700
Message-ID: <CABkgnnXmioyUCQ1EEQPL09a-vZE8-anx5WcQCSkGWB9nzJKOdg@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC