IETF Logo Mail Archive

Re: Rationalise HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME

Daan De Meyer <daan.j.demeyer@gmail.com> Thu, 08 August 2019 19:29 UTC

Return-Path: <daan.j.demeyer@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238581200B8 for <quic@ietfa.amsl.com>; Thu, 8 Aug 2019 12:29:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 wAM2gZ1gnvtp for <quic@ietfa.amsl.com>; Thu, 8 Aug 2019 12:29:27 -0700 (PDT)
Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0737A12002F for <quic@ietf.org>; Thu, 8 Aug 2019 12:29:27 -0700 (PDT)
Received: by mail-ot1-x32a.google.com with SMTP id r6so123193677oti.3 for <quic@ietf.org>; Thu, 08 Aug 2019 12:29:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=tL5Z33zNtfZzZPzabCnoJIebDs6w48fDFvzuY2kE4YY=; b=qASgB+PI+RhVB0aOlChrKOCkLQOslNxI4Wp1Kv4H+71bVYlewsezamI/nM1gWreilj FIn4/4WxUACmsvwUhTO+tJEfZLDZmiua7VrAIuGOjyhVXp9/I/pgJPCjBWJX071+nrpc IXl1A0NWCU/qCX4LLuwKjdnyXn/6b+b+Dok7ngqHZLhNUeawCTwomUjvNPkVX2XY+A1R Jb5SeH8W3SAYZBYRBQZWyTufXTCoA+Xl4H4tx4OpRLWurLIVRNESnDvJrOzcbNYU10rF AyyKbMyR1UV2PuuPJ33TJnNR+mkBBzT7GDKTUgQj+qL29xPe6E+OY7g/NbsjT7p0A8Sj yvhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=tL5Z33zNtfZzZPzabCnoJIebDs6w48fDFvzuY2kE4YY=; b=T9wwcYp9lEUcpCAGqah4ESypBzawW/UhbikRu/C2iZlk2tF2h1bXBUo+PkzR5yC/nn yWsg+4MJPfz9/hRRz/sW8215lvAQp5ZyRvFmAzjlKkV+tNwLYNU1O0Eyg5j+SFLqh203 YtqGVVjTiE+icjDkxpOLe+N4QMyJjVS3tYx+RumCYO44mVz7l/wUFXKt/NrOQfXzTiQP tn51yBZgvVWfTBeK8+OO54fAbGXEqW6JViAWLu2KO5uSJLP75JHhIMKP41q45APJ6l6+ RfpI9v6lJHI3L7cI4Mo+ru3SlQxScz9O20A0XNuTnmBUXe+RMyHf3F63mZ6jfWhaYV1b TZmg==
X-Gm-Message-State: APjAAAVXSWK4wWW4Lr1XiOayWBasHqCCTYF2Kpt8PQhbMFwyG/mQafXU zkRtsXCMT2svANVuvCgtgmcBPx8p5ZlvF6nLrdM=
X-Google-Smtp-Source: APXvYqy5gmNfP3MbJvIVHwLo8y2kSTwNCp7Xq0oEkZXmWifqOBD3J9EJ3L78hkItNk5sDuFp3TpzcngAAjEDezX3+tA=
X-Received: by 2002:a02:c916:: with SMTP id t22mr17971542jao.24.1565292566303; Thu, 08 Aug 2019 12:29:26 -0700 (PDT)
MIME-Version: 1.0
References: <CALGR9ob7=MzO5qt987dpBAxBqnsMRvkrgYz7svktKsMNNhjAdw@mail.gmail.com> <CAO8sHck2XYMiPZgndDm1Cc1xmvWQM=BQpK-+FJxM9g4XXy0FWw@mail.gmail.com> <CY4PR22MB09839B9D42D8DD8AB087FDDBDAD70@CY4PR22MB0983.namprd22.prod.outlook.com>
In-Reply-To: <CY4PR22MB09839B9D42D8DD8AB087FDDBDAD70@CY4PR22MB0983.namprd22.prod.outlook.com>
From: Daan De Meyer <daan.j.demeyer@gmail.com>
Date: Thu, 08 Aug 2019 21:29:15 +0200
Message-ID: <CAO8sHc=+h2GZc3vjskLc5O9Sv=o4k51s2Fo4aHMUk12+W51OVA@mail.gmail.com>
Subject: Re: Rationalise HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME
To: Mike Bishop <mbishop@evequefou.be>
Cc: Lucas Pardue <lucaspardue.24.7@gmail.com>, QUIC WG <quic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/lvAYrmHd_BympmZs3xvkWDVGnl4>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Aug 2019 19:29:29 -0000

Of course, that's completely right. I forgot to mention that unknown
frame types are already ignored when I'm parsing frames so when my
implementation is at the point where it switches on frame type to
determine the next action to take, all unknown frame types have
already been ignored.

Regards,

Daan

On Thu, 8 Aug 2019 at 21:15, Mike Bishop <mbishop@evequefou.be> wrote:
>
> That would be a dangerous coding pattern.  You're required to ignore frames you don’t understand -- that's what allows unnegotiated extension frames.  These error codes are explicitly for frames that you *do* understand and therefore know that they shouldn't be used in the way they are.
>
>
>
> -----Original Message-----
> From: QUIC <quic-bounces@ietf.org> On Behalf Of Daan De Meyer
> Sent: Wednesday, August 7, 2019 10:05 AM
> To: Lucas Pardue <lucaspardue.24.7@gmail.com>
> Cc: QUIC WG <quic@ietf.org>
> Subject: Re: Rationalise HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME
>
>
>
> (I accidentally only replied to Ian so I'm reposting to the entire list)
>
>
>
> Is there a significant amount of added value by having both HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME? If these errors will only be used for debugging and compliance testing in practice, I think we can definitely get away with just reporting HTTP_UNEXPECTED_FRAME whenever a frame is received that isn't supposed to be received at that point in the connection on that stream.
>
>
>
> As a very minor nitpick, having only HTTP_UNEXPECTED_FRAME also simplifies error handling in implementations as a default case can be added on a switch on frame type that throws HTTP_UNEXPECTED_FRAME for every frame type that isn't explicitly handled in the switch statement. Currently, one has to differentiate between frame types that should be reported as HTTP_WRONG_STREAM and frame types that should be reported as HTTP_UNEXPECTED_FRAME.
>
>
>
> My recommendation would be to replace all usages of HTTP_WRONG_STREAM by HTTP_UNEXPECTED_FRAME as in my opinion having both does not add significant value.
>
>
>
> Regards,
>
>
>
> Daan De Meyer
>
>
>
> On Wed, 7 Aug 2019 at 02:03, Lucas Pardue <lucaspardue.24.7@gmail.com> wrote:
>
> >
>
> > Hello WG,
>
> >
>
> > As part of the HTTP error analysis and feedback, in June I created issue #2809 "Rationalise HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME" [1].
>
> >
>
> > In short, HTTP_WRONG_STREAM is used for connection errors when a non-allowed frame is received by a peer (e.g a server receiving PUSH_PROMISE), or when a request sequence is malformed. HTTP_UNEXPECTED_FRAME is used for connection errors when an allowed frame is received on the wrong type of stream (e.g. a client receiving PUSH_PROMISE on the control stream).
>
> >
>
> > Issue 2809 suggests combining these error codes but I've yet to make a PR.. In the meantime, a fair amount of error code refactoring has taken place and I'm not sure how much demand there is for the change.
>
> >
>
> > If you have an opinion on this I'd appreciate feedback here or on the ticket.
>
> >
>
> > Cheers
>
> > Lucas
>
> >
>
> > [1] https://github.com/quicwg/base-drafts/issues/2809
>
>

v2.23.0 | Report a Bug | By Email