Re: #541: CONTINUATION

Nicholas Hurley <hurley@todesschaf.org> Wed, 02 July 2014 17:57 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26DA61B29D5 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 2 Jul 2014 10:57:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.93
X-Spam-Level:
X-Spam-Status: No, score=-6.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sj-Ba8w3SOE for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 2 Jul 2014 10:57:14 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E57A1B29B7 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 2 Jul 2014 10:57:14 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1X2Ojq-0005WA-QW for ietf-http-wg-dist@listhub.w3.org; Wed, 02 Jul 2014 17:54:34 +0000
Resent-Date: Wed, 02 Jul 2014 17:54:34 +0000
Resent-Message-Id: <E1X2Ojq-0005WA-QW@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <hurley@todesschaf.org>) id 1X2Ojl-0005VP-VJ for ietf-http-wg@listhub.w3.org; Wed, 02 Jul 2014 17:54:29 +0000
Received: from mail-ve0-f180.google.com ([209.85.128.180]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <hurley@todesschaf.org>) id 1X2Ojk-0002VD-UH for ietf-http-wg@w3.org; Wed, 02 Jul 2014 17:54:29 +0000
Received: by mail-ve0-f180.google.com with SMTP id jw12so11708200veb.11 for <ietf-http-wg@w3.org>; Wed, 02 Jul 2014 10:54:03 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=NsIcMyOQY7dJNSG8E0wWCZGWWfztSnapTyUaBoUH3p0=; b=A/dai+uWxs5cOC0Kg9j38AK/2LsEt03BSTXtYd2NWRfkTb7maGCJI7g4u6fFbGQ8Eo TcdJS8boOIWXfqLxNVYU1/Mf9uW0Uelsqzs60DLTEOYmUbgnIHtc+Cgwb42Athjeu5Md j/g8+lJXdfZBIOkCDht/hGrDIXO3GPv+skBJ1XISIM0Hj2F4WtR/rWy3irsDeLL00OMX en3Hk5OEWA65Vzbj6WSD6/QvIBYWfdN1Fu/xdhW8YCREEPdABHDjCdkN3+ID757mOQ8H X2oVOkmCxB90nvudiyCNItNjfudsWowaHpQlKlh2Pa4m/MQak44qglXxXJeFscN3N7+t 4zUQ==
X-Gm-Message-State: ALoCoQm03a6Q0gH7+XYRkRVEpkk/aSAk5+HJ9bS4+k8DyxM2FyVE28vE9FGUtGIOkUzo6aKHfuZO
MIME-Version: 1.0
X-Received: by 10.52.248.146 with SMTP id ym18mr42398426vdc.8.1404323642879; Wed, 02 Jul 2014 10:54:02 -0700 (PDT)
Received: by 10.220.225.198 with HTTP; Wed, 2 Jul 2014 10:54:02 -0700 (PDT)
X-Originating-IP: [50.0.37.52]
In-Reply-To: <0E4E566E-11DF-4D52-9163-C836B5F93120@mnot.net>
References: <0E4E566E-11DF-4D52-9163-C836B5F93120@mnot.net>
Date: Wed, 02 Jul 2014 10:54:02 -0700
Message-ID: <CANV5PPXs_-N6iFysw3jGXEn89JHR6oV5F4yK=UEGaZknskR-9Q@mail.gmail.com>
From: Nicholas Hurley <hurley@todesschaf.org>
To: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="089e0111debce24d8b04fd399377"
Received-SPF: pass client-ip=209.85.128.180; envelope-from=hurley@todesschaf.org; helo=mail-ve0-f180.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.767, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1X2Ojk-0002VD-UH 29782316e5fb5be39d6d21f37b16b1ce
X-Original-To: ietf-http-wg@w3.org
Subject: Re: #541: CONTINUATION
Archived-At: <http://www.w3.org/mid/CANV5PPXs_-N6iFysw3jGXEn89JHR6oV5F4yK=UEGaZknskR-9Q@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/25168
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

[Trimmed CC]

Speaking from the perspective of working on both Firefox (client) and (more
recently) node-http2 (server) implementations, I strongly prefer keeping
the status quo. I have seen no arguments at this point that convince me
that a relatively large change to how we compress and frame headers is in
any way required. We're talking about handling (iirc) 0.02% of the cases
here, and I frankly think it makes sense to say that if you've received
more compressed (or uncompressed!) headers than you're willing to deal
with, then just send a RST_STREAM and process and discard any remaining
HEADERS/CONTINUATION frames on that stream (or send a GOAWAY if you feel
you're in a DoS situation). It seems to me that a robust implementation
will already have a facility to process and discard HPACK data anyway, to
handle other situations where you may decide while receiving headers that
you don't want the stream.

I *could* work with stateless CONTINUATION frames in both of these
implementations, though it would still require rolling back the state of at
least one encoded header (once it's determined that the encoding would
cause a crossing of the 16k boundary). It also breaks the separation of
concerns between HPACK and the framing layer in a way that I find
*significantly* less than appealing. As such, even though I won't burn
things down if this is the option the WG comes to consensus on, I won't go
down without a fight :) To be clear, there is nothing in my server-side
implementation experience that has indicated to me that even this
alteration is necessary, or even a nice-to-have.

None of the other options are acceptable to me.
--
Peace,
  -Nick


On Wed, Jul 2, 2014 at 4:12 AM, Mark Nottingham <mnot@mnot.net> wrote:

> <https://github.com/http2/http2-spec/issues/541>
>
> There’s been strong pushback on the current design of CONTINUATION from
> some interested parties, and a few implementers. Despite the fact that this
> design is the result of multiple meetings demonstrating strong consensus,
> and the fact that we have a schedule-focused charter, this issue deserves a
> good hearing.
>
> I think everyone now has an idea of the issues and trade-offs involved, as
> well as the potential end-games. We also helpfully have a few proposals on
> how to move forward:
>
> 0) the status quo
>
> 1) <https://github.com/http2/http2-spec/pull/544> and variants thereof
> (e.g., not including CONTINUATION in flow control; alternative syntaxes)
>
> 2) limiting header sizes to 16K (HPACK’d) in HTTP/2, as per PHK’s
> suggestion
>
> There’s also another implicit option;
>
> 3) We can’t know until we get substantial interop and deployment
> experience with draft-13.
>
> I’d like to ask the implementers (as identified on the CC: line) what
> their preferences are, and what they can’t live with. If there’s another
> option, please say so, but only if it’s materially different, and you
> believe it has a chance of achieving consensus.
>
> To be clear, if you don’t say that you can’t live with something, it means
> that it’s an acceptable outcome. If you do, be prepared to back up such a
> strong stance with an equally strong argument.
>
> Note that this is input to help determine consensus, not a vote.
>
> Thanks,
>
> P.S. Please keep in mind that (3) is not “wait until September, then
> decide it’s too late.” Achieving a reasonable consensus now is relatively
> pain-free, if possible; deadlocking right before we (want to) ship is
> something I want to avoid.
>
> P.P.S. To anticipate some responses, a generic “jumbo frame” is off the
> table for this discussion; doing so doesn’t appear to have broad support,
> and there are strong arguments against it.
>
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>
>