IETF Logo Mail Archive

Re: [Masque] HTTP DATA frames for HTTP CONNECT?

Ian Swett <ianswett@google.com> Tue, 20 October 2020 22:06 UTC

Return-Path: <ianswett@google.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 09BCB3A1404 for <quic@ietfa.amsl.com>; Tue, 20 Oct 2020 15:06:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.6
X-Spam-Level:
X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 Wub5ffgUXRKM for <quic@ietfa.amsl.com>; Tue, 20 Oct 2020 15:06:05 -0700 (PDT)
Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (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 3850E3A1402 for <quic@ietf.org>; Tue, 20 Oct 2020 15:06:05 -0700 (PDT)
Received: by mail-yb1-xb2e.google.com with SMTP id a12so3227469ybg.9 for <quic@ietf.org>; Tue, 20 Oct 2020 15:06:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uxyiR/RieMf7djWndo8v/Toz22+VDlafF+iEcD+PcW0=; b=fal2F/pQt2w8hZNd+KVag//Rsjl62b23wAruHCaArEo3J4C6i9lqyaW2kLReJEA3PC LmLhwliSlzygbdHHPR4PQN2xEKRz99D36Otrajk8bXNYTGplZjBJXrGOh8q2LPiYBsNK zZ9spMAK3tD7xV4vEE5gQi/h3RT3Y1GOmoxkV+x6B/tfcgTNu/CrUwWR+siYFvcKrIY5 +7hCmE3ztq/2AZn3F34jpLwNGxX8u9w9lDuwXE49lIqCAb3Q4FrEhSO0dtfPJq8v8uQg soQd+AD+ZwLG0Od7UVPzIGfhoqA/1qp8ixF4XBkAI2ZHohWqt3JqaTY/Awx6XhzKfvLB naIw==
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; bh=uxyiR/RieMf7djWndo8v/Toz22+VDlafF+iEcD+PcW0=; b=IyYq8u1GySdYauY9c1zunJplu66R+bPTel2myn7cOJo7WUNskk23qgfr0Q25Bd0IZh n14aDdBYk8yGnQf5so+RJbf9l9QWBatCfM76/qr7UMxkBj6vumKKTRGuD+uGbzvHeY3D +oygIG8tzhWzXIUOto7v2L1ldPGpLjA1q+xnmvxmNi8kcZwc+pk+BMAWI4qqYtwXs/wB MQ7sBJDw+dr/LiiLKjr94GDBsK2z+UMIF7vLG5GXHz61NZr8ve8QKp3vjrMGnrDmiKgK PomvWfL4vKpyx7PEbpry+spm+7RODgnw4zf64TD1MA+7vf0Ehbv7pkV/wjpz7POEpnsc /CFQ==
X-Gm-Message-State: AOAM533bWTHscUZuvKbrtBXzks5LmHk/VG3ij0CFG+l23kgwHCSqaNUh D/Y0C+oC7PNzH8BjqhsdvDoTzL8uzymAeZ2zNqJ/3g==
X-Google-Smtp-Source: ABdhPJwrJyVjPrKqBzT5dW/TC2FcZZIJMSwrLM++fljIt+SaUxWsoWoDdFDz5gD1eyv3maRh8WtYLUldAK2jDVxV768=
X-Received: by 2002:a5b:d02:: with SMTP id y2mr771411ybp.389.1603231563972; Tue, 20 Oct 2020 15:06:03 -0700 (PDT)
MIME-Version: 1.0
References: <A92255DF-F477-4DE6-9AA2-33373959E792@ericsson.com> <MN2PR22MB20934245C43D7DDA5BC8F5D4DA020@MN2PR22MB2093.namprd22.prod.outlook.com> <MN2PR22MB20933D2E25F5425EA848E0D7DA020@MN2PR22MB2093.namprd22.prod.outlook.com> <CAPDSy+62-q83vK0zuPs9kQXP4Akm6KX5Khp1q4PD_2wDpacKNw@mail.gmail.com> <A50ACE49-E067-44ED-988D-B70E261482ED@ericsson.com> <CALGR9oa9_OapmpK721SQG4iOboJiTgnmNfSEO9Rwb4Mq110bNA@mail.gmail.com> <2CEC578A-32A5-45C4-B3A9-F615C9EB9DBE@ericsson.com> <CALGR9obHNAvKgTM97uhK+KAEf1ua6D3dW5x2HUOoV0QVUROY9w@mail.gmail.com> <B92228CD-6AA0-40BE-AFA3-223AD17285F2@ericsson.com> <CALGR9oZKJ7vbmZDh74k0gsX2r4nkeEE3VRrrywozT0iqQRGfGA@mail.gmail.com>
In-Reply-To: <CALGR9oZKJ7vbmZDh74k0gsX2r4nkeEE3VRrrywozT0iqQRGfGA@mail.gmail.com>
From: Ian Swett <ianswett@google.com>
Date: Tue, 20 Oct 2020 18:05:52 -0400
Message-ID: <CAKcm_gNeRs9zCyEFweiwPFV_wYXf4LAjYE9q+AoGEnqnTjeq=w@mail.gmail.com>
Subject: Re: [Masque] HTTP DATA frames for HTTP CONNECT?
To: Lucas Pardue <lucaspardue.24.7@gmail.com>
Cc: Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>, David Schinazi <dschinazi.ietf@gmail.com>, QUIC WG <quic@ietf.org>, Mike Bishop <mbishop@evequefou.be>, MASQUE <masque@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000dd825705b2216fd3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/OQOwBDggvTuyK86h-EGqRi0FD3s>
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: Tue, 20 Oct 2020 22:06:07 -0000

I'm coming to this conversation late in the game, but this was discussed
fairly extensively on https://github.com/quicwg/base-drafts/issues/1885

And I do believe it's an annoyance, since adding an extra layer of framing
can greatly increase code complexity, harm performance, or both.

However, now that I re-read the HTTP draft, I wonder if it's legal to send
a DATA frame with a huge size and then let the QUIC stream close?  I
couldn't find any text specifically describing what to do in the case where
the DATA frame length does not match the number of bytes read prior to the
QUIC stream being closed, but possibly I missed something.  If this is
allowed, it seems functionally equivalent to the proposal to treat 0 length
DATA frames as terminated when the stream is closed.

Ian

On Mon, Oct 19, 2020 at 7:26 AM Lucas Pardue <lucaspardue.24.7@gmail.com>
wrote:

> The library doesn't inspect request methods. Doing so for CONNECT would
> create a disparity, which is an excellent way to create bugs.
>
>
>>
>>

v2.23.0 | Report a Bug | By Email