Re: HTTP/3 Preface (PRI method)

Matt Joras <matt.joras@gmail.com> Tue, 29 June 2021 19:31 UTC

Return-Path: <matt.joras@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 25F603A0783 for <quic@ietfa.amsl.com>; Tue, 29 Jun 2021 12:31:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 qywvoQXoL9qG for <quic@ietfa.amsl.com>; Tue, 29 Jun 2021 12:31:09 -0700 (PDT)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 344943A3E96 for <quic@ietf.org>; Tue, 29 Jun 2021 12:31:09 -0700 (PDT)
Received: by mail-lf1-x12e.google.com with SMTP id q18so329889lfc.7 for <quic@ietf.org>; Tue, 29 Jun 2021 12:31:09 -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; bh=+MO4dVz6us8dE0h/MqWcR3hZPo7iN2ZlVhvY00ID4mY=; b=UaUk3rIBocJGDQrOWiM2H6NJVIgLGGgGKEkVGK9Czko9XtxITS5K4I+QRnHur7FJMA iRjXynalSoIls3jW7mJu9GB8c6D33P/FP15Q6Ds4oIY4zeJ2lYRKeWMvpMWV2l22mMh/ ghs5QSLyUCyke0EBaTIgdy/WQOFINcuunitzDMUn0MAabUB52EUPfkSfYbHPo2Whdp66 uDu5rUaedtP1nJAtUwYEdnSGnC1MHsG2HBUAT0nRrBdqLZsVKCjjuYZvv+cPSfVqXWNx l70fmgp03HVU9MBGpUSg0l52YJ/sjalvTKDhETYEpWMlUfzyAtwFpnyJNG8kPkYxwU4R hLIw==
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=+MO4dVz6us8dE0h/MqWcR3hZPo7iN2ZlVhvY00ID4mY=; b=r4it2VI5Pq3gAUF8FwOvkhg0lE8e7HRQ0nRBVua9Bxkv9MV4hv0wn3WIioF13eaNNw mzTAcbeRi/M+bHs8gRpwwjIYW7eZIk9X3UaE0+c7zoGZlbn2V7g5wc3usgHLeGZ+iqqT UR+aetgET1k05Q+cKq374hq2fO1T7RonhqNHPGaYcF5cT7ts8nvfPy5VUPDIRTLy7xL1 U79SHrR2vdLYiEEfuJ6fiVdTE9Jryw8YyVJY1aJy84HQFEY3H/q4nhcmTX9JJaF3wMlS YaGpVQSzk1z2SUfDghv/4XvCaH500v1Ljio0FVeeZIrng/Nebwk2F1TRWUf49OFsmXmU Z+IA==
X-Gm-Message-State: AOAM530eELgif7gUVZKVRm/We2cJCzot0AERWDihhG0OcCk3FJbHUQHM TQX6VAN3mhBbnLIDzQhWfT3APV+fGtVmCvlMX6k=
X-Google-Smtp-Source: ABdhPJx45BhQFDU8kjXk8N7jgmj0VzCmlhABB3/YXVbjTaV5zjP2RmPtZSCFaIdhQzEvc+nyCxjdl2Q65WithyHPP6g=
X-Received: by 2002:ac2:4e09:: with SMTP id e9mr23840004lfr.434.1624995065569; Tue, 29 Jun 2021 12:31:05 -0700 (PDT)
MIME-Version: 1.0
References: <4723f90d822b18e3d0402b6496ac1d02@yocto.nu>
In-Reply-To: <4723f90d822b18e3d0402b6496ac1d02@yocto.nu>
From: Matt Joras <matt.joras@gmail.com>
Date: Tue, 29 Jun 2021 12:30:54 -0700
Message-ID: <CADdTf+im9s_A4LXiwR15R=iLr6X8PJR=J3xq7302WWeGEiOy1A@mail.gmail.com>
Subject: Re: HTTP/3 Preface (PRI method)
To: ben=40yocto.nu@dmarc.ietf.org
Cc: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a5246405c5eca5ef"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/_XOkUmiGhkxKqHYU_z7XfufPrV4>
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, 29 Jun 2021 19:31:14 -0000

Hi Ben,

This issue in general, if I'm understanding you correctly, is solved via
the ALPN[1]. I.e., as part of the TLS handshake the server will be able to
know which application is being used. For example, "h2" corresponds to
HTTP/2 and "h3" corresponds to HTTP/3. Also note that there are no
standardized mappings of HTTP over QUIC except for the currently-pending
HTTP/3 specification. Future versions of HTTP over QUIC would also be
distinguished via ALPN, presumably.

Best,
Matt Joras

[1] https://datatracker.ietf.org/doc/html/rfc7301

On Tue, Jun 29, 2021 at 12:11 PM <ben=40yocto.nu@dmarc.ietf.org> wrote:

> Hello all,
>
> When reading about QUIC, it comes to me as a better alternative of TCP,
> build upon UDP.
> In this case, servers that run on TCP could easily also run on UDP/QUIC;
> think about DNS, SMTP, FTP.
>
> Now there is also a new version of HTTP. HTTP/3. This version will be
> transfered over QUIC by default.
> However, as I mentioned above, it could be possible to have "TCP
> protocols" that use QUIC too.
> That makes me think about also transfering some old HTTP versions, for
> example HTTP/0.9 (I came across a library that transfered HTTP/0.9 over
> QUIC).
> But also HTTP/1.0, HTTP/1.1 and HTTP/2 are possible.
>
> All older HTTP versions send the following request line: <METHOD> <PATH>
> [VERSION] \n
> If an endpoint is directly accessed (without some negotiation), it will
> find out the version directly by reading the first line.
> For 0.9 the version will be absent. For 2.0 this will be a preface with
> a PRI method and * as path.
>
> When I think about running a HTTP server, I think about this:
>
> TCP (80) or TCP/SSL (443):
>   - HTTP/0.9
>   - HTTP/1.0
>   - HTTP/1.1
>   - HTTP/2.0
>   - HTTP/3.0 (I think this is possible too)
>
> UDP/QUIC:
>   - HTTP/0.9 (HTTP/0.9 but over QUIC)
>   - HTTP/1.0 (HTTP/1.0 but over QUIC)
>   - HTTP/1.1 (HTTP/1.1 but over QUIC)
>   - HTTP/2.0 (HTTP/2.0 but over QUIC)
>   - HTTP/3.0 (Default)
>
> However, if I listen for all versions on my HTTP-QUIC server, how am I
> supposed to know that it is HTTP/3? Does HTTP/3 has a preface? And if
> not, why not?
> I think the preface of HTTP/2 is great and I think it would be great in
> HTTP/3 too: PRI * HTTP/3.0
>
> I would like to see a preface added to HTTP/3.0. It is only 18 extra
> bytes at the beginning of the request. It could be ignored by some
> servers if they want, but for servers that want to have backwards
> compatibility it would be a great feature. (Luckily HTTP/3 is not a
> released standard yet.)
>
> Ben
>
>