Re: [#150] Making certain settings mandatory
Roberto Peon <grmocg@gmail.com> Sat, 29 June 2013 19:42 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 (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D85F621F9FE3 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 29 Jun 2013 12:42:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kW96DYFpukCZ for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 29 Jun 2013 12:42:31 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id DC9A221F9FDF for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sat, 29 Jun 2013 12:42:25 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1Ut11w-0002vG-Jd for ietf-http-wg-dist@listhub.w3.org; Sat, 29 Jun 2013 19:41:56 +0000
Resent-Date: Sat, 29 Jun 2013 19:41:56 +0000
Resent-Message-Id: <E1Ut11w-0002vG-Jd@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1Ut11i-0002pz-F3 for ietf-http-wg@listhub.w3.org; Sat, 29 Jun 2013 19:41:42 +0000
Received: from mail-oa0-f47.google.com ([209.85.219.47]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1Ut11h-0006ZW-Ik for ietf-http-wg@w3.org; Sat, 29 Jun 2013 19:41:42 +0000
Received: by mail-oa0-f47.google.com with SMTP id m1so3547679oag.34 for <ietf-http-wg@w3.org>; Sat, 29 Jun 2013 12:41:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0uFeonPzxrXsWmGc5qKxqB59zo1sbJ/qnfKSLu366pQ=; b=xgcsiuUdjuD3euv/vWdeB7HtTi6EUWOh+nr9BIC1MbZ/31HE3syP9c5zzBVY3OO3t7 YI/D3NDowH9hK0mkjyoihfB27HIe7xhnujAMyhpLl+fgCg1je+g0xQH6EETxj6hIzMb1 0jOnivtPwCU8INffV+bGuF5Z2JDdLKLvBfECEuhkvYapRm9/4GMYRMnsykzWw1A2NT9n nRBsxyo3N0/FzvPJBmghihDUzcyxEEKdH24WlIqJkRraW/IRiu4o1iSpcA/ZO9T74KNR PeeRArLB8Phc2YSCLgjcNuOopEoAR4MKMFvGLbscy5ZE+wFbQzMTIazsSuontRGkvTxo 8d2A==
MIME-Version: 1.0
X-Received: by 10.60.45.38 with SMTP id j6mr7181280oem.56.1372534875615; Sat, 29 Jun 2013 12:41:15 -0700 (PDT)
Received: by 10.76.91.229 with HTTP; Sat, 29 Jun 2013 12:41:15 -0700 (PDT)
In-Reply-To: <CA+pLO_hpmFbDNyaPgi3JhtRSdKnTEGsv0_NXxL2BTJfUJ4xStw@mail.gmail.com>
References: <CABkgnnW2xi3pAKyg2Abi15Gb11ZCFi+D_QUQw1566BVXb65iHg@mail.gmail.com> <CABaLYCs8vb35CoL+A4mh7-PkbnKXxjz+jCJ_z-ivzYnYKF=VWQ@mail.gmail.com> <CA+pLO_gFrAow2==sZx8_57Hw81d24V4HaqJCEc63WhZSAoWdBA@mail.gmail.com> <CAP+FsNd9dVzRBv1iXS59XQEkk32rK9EtfQs=c1rp+yYHSbG5dQ@mail.gmail.com> <CA+pLO_ijfgbkYEKXn3xUq5-Kxw69k4oQhMc8+fL5tTtenN2x3A@mail.gmail.com> <CAP+FsNfO140h4UgS55P6Ouj2vEc7ZCZzGTBOWRD7+1DigRNUMw@mail.gmail.com> <CA+pLO_hpmFbDNyaPgi3JhtRSdKnTEGsv0_NXxL2BTJfUJ4xStw@mail.gmail.com>
Date: Sat, 29 Jun 2013 12:41:15 -0700
Message-ID: <CAP+FsNeq+xUKjVU3uLFGy-2uozErq5fbJ20bD85zNvz=PHJqSQ@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: Jeff Pinner <jpinner@twitter.com>
Cc: Mike Belshe <mike@belshe.com>, Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="089e015367ecb3f5e304e0502d15"
Received-SPF: pass client-ip=209.85.219.47; envelope-from=grmocg@gmail.com; helo=mail-oa0-f47.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.677, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1Ut11h-0006ZW-Ik 5d5adde7b13dca7047db7159668d3d3e
X-Original-To: ietf-http-wg@w3.org
Subject: Re: [#150] Making certain settings mandatory
Archived-At: <http://www.w3.org/mid/CAP+FsNeq+xUKjVU3uLFGy-2uozErq5fbJ20bD85zNvz=PHJqSQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18424
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>
This is why it seems like this doesn't make sense to me- we're proposing to tear down the connection for an error which neither causes corruption, nor causes state mismatch. This also does nothing to reduce complexity. We've moved a conditional from the startup, which is already special in the first place (the magic string) to elsewhere, while requiring more bytes on the wire and more ways to randomly/accidentally tear down the connection. This requirement also does nothing to simplify the parsing of the settings frame, as it might contain other settings, especially in the future. -=R On Sat, Jun 29, 2013 at 12:31 PM, Jeff Pinner <jpinner@twitter.com> wrote: > If it's a MUST and the required settings aren't there you'd have to close > down the connection, same way you would for any other badly formatted frame > that you couldn't interpret. > > > On Sat, Jun 29, 2013 at 12:30 PM, Roberto Peon <grmocg@gmail.com> wrote: > >> Again, what happens when the required settings are not in the frame? >> >> >> On Sat, Jun 29, 2013 at 12:20 PM, Jeff Pinner <jpinner@twitter.com>wrote: >> >>> If you don't want them to be mandatory then don't make them mandatory as >>> part of the Upgrade mechanism and rely on the defaults if you choose to >>> upgrade without including them. >>> >>> Consistency :) >>> >>> >>> On Sat, Jun 29, 2013 at 12:16 PM, Roberto Peon <grmocg@gmail.com> wrote: >>> >>>> Ug. Slippery slope. >>>> I'm happy to say the settings frame is mandatory, you SHOULD send >>>> settings you care about in the initial settings frame, and otherwise you >>>> get what you get. >>>> >>>> This is less complicated. What would be the result of not having the >>>> mandatory fields in the settings frame as proposed above? If it isn't >>>> 'close down the connection', the requirement is useless. >>>> >>>> -=R >>>> >>>> >>>> >>>> On Sat, Jun 29, 2013 at 12:03 PM, Jeff Pinner <jpinner@twitter.com>wrote: >>>> >>>>> +1 To consistent handling of frames, whatever the rules are. >>>>> >>>>> >>>>> On Thu, Jun 27, 2013 at 11:05 AM, Mike Belshe <mike@belshe.com> wrote: >>>>> >>>>>> I believe the bytes are completely inconsequential. >>>>>> >>>>>> My goal with this was to make it so there is only one set of rules >>>>>> for SETTINGS frames. Currently, there is the "oh this is the first >>>>>> settings frame rules". >>>>>> >>>>>> This is not going to have impact on performance, but removing edge >>>>>> cases is desirable to me. >>>>>> >>>>>> Mike >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Jun 27, 2013 at 10:27 AM, Martin Thomson < >>>>>> martin.thomson@gmail.com> wrote: >>>>>> >>>>>>> This pull request proposes to make two settings mandatory in every >>>>>>> SETTINGS frame: SETTINGS_MAX_CONCURRENT_STREAMS and >>>>>>> SETTINGS_INITIAL_WINDOW_SIZE. >>>>>>> >>>>>>> https://github.com/http2/http2-spec/pull/150 >>>>>>> >>>>>>> Gabriel's proposal for an HTTP/1.1 header for carrying settings in >>>>>>> the >>>>>>> Upgrade made these mandatory only at that point, which didn't cover >>>>>>> the TLS handshake, or just starting from prior knowledge. >>>>>>> >>>>>>> Two questions: >>>>>>> - Do we want to make any settings mandatory, or are defaults >>>>>>> acceptable? >>>>>>> - Is this the right trade-off? Or are the 16 bytes on subsequent >>>>>>> SETTINGS frames completely intolerable. >>>>>>> >>>>>>> Note that if we make these settings mandatory, there might be other >>>>>>> settings in the future that will also be mandatory; e.g., the >>>>>>> compression context size. >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
- [#150] Making certain settings mandatory Martin Thomson
- Re: [#150] Making certain settings mandatory Mike Belshe
- Re: [#150] Making certain settings mandatory Jeff Pinner
- Re: [#150] Making certain settings mandatory Roberto Peon
- Re: [#150] Making certain settings mandatory Jeff Pinner
- Re: [#150] Making certain settings mandatory Roberto Peon
- Re: [#150] Making certain settings mandatory Jeff Pinner
- Re: [#150] Making certain settings mandatory Roberto Peon
- Re: [#150] Making certain settings mandatory Jeff Pinner
- Re: [#150] Making certain settings mandatory Roberto Peon
- Re: [#150] Making certain settings mandatory Eliot Lear
- Re: [#150] Making certain settings mandatory Jeff Pinner
- Re: [#150] Making certain settings mandatory Eliot Lear