[quicwg/base-drafts] Add capability for sending HTTP metadata (trailer fields) in mid-stream (#3265)

"Roy T. Fielding" <notifications@github.com> Tue, 19 November 2019 02:56 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 925A1120BA0 for <quic-issues@ietfa.amsl.com>; Mon, 18 Nov 2019 18:56:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 h7aYjM3AVq9V for <quic-issues@ietfa.amsl.com>; Mon, 18 Nov 2019 18:56:43 -0800 (PST)
Received: from out-11.smtp.github.com (out-11.smtp.github.com [192.30.254.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBC90120BEB for <quic-issues@ietf.org>; Mon, 18 Nov 2019 18:56:43 -0800 (PST)
Received: from github-lowworker-cde56e0.va3-iad.github.net (github-lowworker-cde56e0.va3-iad.github.net [10.48.25.52]) by smtp.github.com (Postfix) with ESMTP id 8D64326164F for <quic-issues@ietf.org>; Mon, 18 Nov 2019 18:56:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1574132203; bh=izY3o189JdY97BN0Y+qqiHJdDJtHgDPbJoJ5Pf6X/LY=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=0qehG0pAOAQ2FiVa4qmOeAoUZamcsA4+lOnw9ZSs7SnW0s5DVdz26qMj9kIUgvev2 cZLV6WGdV2N7FF+Bt4R6BRBcptzLrRj6ihPe6Kzvv/RFD1tJxg29rYI4X+wKaobnH+ aadltKUrxzZ2dSFNIuBcgL6uHwPyr4uUYY3Dy8T4=
Date: Mon, 18 Nov 2019 18:56:43 -0800
From: "Roy T. Fielding" <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK45FWMIQR54C2IUUB534CGGXEVBNHHB6RXLXM@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3265@github.com>
Subject: [quicwg/base-drafts] Add capability for sending HTTP metadata (trailer fields) in mid-stream (#3265)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5dd359eb483a9_32163fd642acd96c94924"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: royfielding
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/c_mUzRj8AUVpPgU6N_Pp8NKrHb0>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Nov 2019 02:56:47 -0000

For a very long time (since early 1995) there have been various attempts to send metadata in parallel with the request or response bodies. The use cases have ranged from group chat to chained digital signatures to performance metrics to long download checkpoints to a heck of a lot of other things that I pretend to no longer remember for sanity purposes.

Fixing that in HTTP/1.1 was only possible within chunked extensions. For a variety of reasons that had nothing to do with the use cases, chunked extensions didn't work well over intermediaries and the chicken never hatched. Nevertheless, they did work over HTTP when the applications had control over both sides of a connection. I vaguely recall such metadata being present in HTTPng as well.

For some bizarre reason, I thought that sending metadata in midstream was present in h2 and all was fine and good for keeping it through in QUIC. I mean, for crying out loud, we don't have any of the limitations here that we had to deal with in HTTP/1.1. That's why I didn't raise this issue earlier. Apparently, I was wrong.

I would like for HTTP/3 to have a mechanism for communicating metadata (like trailers) in mid-stream, both for requests (e.g., priority) and responses (e.g., chained sigs).

I believe that this can be done with an additional frame type that carries trailer data, just like HEADERS, but that doesn't imply the end of DATA. However, I don't really have an opinion on what is the right way to do this in HTTP/3, only that it is worthwhile and necessary to do before a last call. I do not believe, from extensive experience, that this feature can be added later. I'd appreciate if people more familiar with QUIC implementation would choose the best specific syntax.

It is not a semantics change for HTTP because the fields are just optional trailers that arrive early. A recipient that is not prepared to handle these fields, for whatever reason, can discard them in the same way as trailers.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3265