IETF Logo Mail Archive

Re: [quicwg/base-drafts] DATA frame encoding is inefficient for long dynamically generated bodies (#1885)

Kazuho Oku <notifications@github.com> Mon, 22 October 2018 21:49 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 48D3D128CB7 for <quic-issues@ietfa.amsl.com>; Mon, 22 Oct 2018 14:49:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.47
X-Spam-Level:
X-Spam-Status: No, score=-8.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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_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 youbk8pqxcrJ for <quic-issues@ietfa.amsl.com>; Mon, 22 Oct 2018 14:49:54 -0700 (PDT)
Received: from out-6.smtp.github.com (out-6.smtp.github.com [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65BE5127AC2 for <quic-issues@ietf.org>; Mon, 22 Oct 2018 14:49:54 -0700 (PDT)
Date: Mon, 22 Oct 2018 14:49:52 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1540244992; bh=3uY3T0b75hl1FaHH0cqn9PIB2BAergVy6dZAyRj/1lU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Lr1HocAgAatGiXVQX29ybinneJrVDItgqSltDidueRPXQFIdCEDZoZkmYn0UpBPdP dn/dVmD6bwZVmLKuU5atY/2irQzUK8kv/AHuPqQPB1OTza+DSYJz8ozgZqVsw3v7ta ACL2aq2yp9c5YCy6l5VEAC55ZvTjUjnDQdDe7k+I=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abd72bee623b7412a99d696623f74c1f501b12cbaf92cf0000000117e6080092a169ce16286866@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1885/432002183@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1885@github.com>
References: <quicwg/base-drafts/issues/1885@github.com>
Subject: Re: [quicwg/base-drafts] DATA frame encoding is inefficient for long dynamically generated bodies (#1885)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5bce4600e902b_62c3fbfa98d45c014038c8"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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/jO5oS_qpw8wKGzojNlnKOzRZuZI>
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: Mon, 22 Oct 2018 21:49:56 -0000

@MikeBishop 
> Technically, don't you have to declare in your header whether there will be trailers and what they will be? So that is actually known if you're parsing the HTTP semantic layer. However, this layer of the mapping doesn't attempt to encode it.

The use of `Trailers` header field is merely a recommendation (i.e. `SHOULD`). And as you point out, there is no signal at the encoding layer. So from an intermediary's perspective, IMO it's just more natural to forward the trailers as they are, regardless of what the value of (or the existence of) the Trailers header is. Though I agree that dropping trailers in case of the absence of the `Trailers` header field will not cause interoperability in practice.

-- 
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/1885#issuecomment-432002183

v2.23.0 | Report a Bug | By Email