IETF Logo Mail Archive

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

Kazuho Oku <notifications@github.com> Fri, 19 October 2018 01:50 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 CED7F130E2F for <quic-issues@ietfa.amsl.com>; Thu, 18 Oct 2018 18:50:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.064
X-Spam-Level:
X-Spam-Status: No, score=-8.064 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, 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 G9IiIBBwfLdZ for <quic-issues@ietfa.amsl.com>; Thu, 18 Oct 2018 18:50:46 -0700 (PDT)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC33F126DBF for <quic-issues@ietf.org>; Thu, 18 Oct 2018 18:50:45 -0700 (PDT)
Date: Thu, 18 Oct 2018 18:50:44 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1539913844; bh=BbSeiIWziMBdC1tRADBBBmuy0aAGGtERFxKqtAjAyZs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=j4gQirrXP0wgkiBx3pdo0t0gjeNXWUnZfX3AKw0gRgTgEdFk7+zv+qknfU9BcLdri f6tMfYWTznE50UVWBgqXFrJpzwjw2P4tmzi8/Nh2OW4LnNpHCAzkyohf2TQt3hNn2E Eeqowfc1hrmBzGSZzyTBZY0JVJZ9MogyH2LHDGTM=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab71fe4966ec0bf8165854e4a1d573e6d12721299d92cf0000000117e0fa7492a169ce16286866@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/431219227@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_5bc93874ebb6a_440b3fc045ad45b810599a4"; 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/6EmrBq0AD3h4K5HC3tVLXEwk2D4>
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: Fri, 19 Oct 2018 01:50:48 -0000

@RyanAtGoogle 
> Instead if would be more efficient if we could set a length of "until end of stream" (encoded as 0 or some such) which would allow the sender to write a single DATA frame header and the simply send the entire body without additional framing.

Doesn't having a "end of stream" signal as part of the frame payload mean that we would need to escape the contents of HTTP if it contains the octets that can be interpreted as the "end of stream" signal?

Assuming that my understanding is correct, this sounds like MIME multipart. I prefer current chunked encoding style above that, because you do not need to scan through the content that you'd be forwarding.

Or am I missing something?

-- 
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-431219227

v2.46.0 | Report a Bug | By Email | System Status