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

Mike Bishop <notifications@github.com> Mon, 22 October 2018 16:12 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 1E67B127AC2 for <quic-issues@ietfa.amsl.com>; Mon, 22 Oct 2018 09:12:00 -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 5117yPpHP9-2 for <quic-issues@ietfa.amsl.com>; Mon, 22 Oct 2018 09:11:58 -0700 (PDT)
Received: from out-3.smtp.github.com (out-3.smtp.github.com [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BD291274D0 for <quic-issues@ietf.org>; Mon, 22 Oct 2018 09:11:58 -0700 (PDT)
Date: Mon, 22 Oct 2018 09:11:57 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1540224717; bh=LD00BOxPtq6cQiBI32MVwacP8y+qZJSeus2+CtCMoss=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=iZKorT6L27wkM6fDtyZ5gwfvVSNch1tSGQsCHT5JatowxxC2+iaP+uA4UAdPmbTOe KOaJkBxizzvqVgzWCQUXX86nbM0pg8mWxzaEoT0jCbd+cG2zevXnazgnGQyYARAcXc ytRdmWPkyfCPhlSnvpDuEO9ANe8Gv/3HXDsJxt/0=
From: Mike Bishop <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abbdf00b81f45b51edd33ccf296f06a9737c418a4d92cf0000000117e5b8cd92a169ce16286866@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/431882189@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_5bcdf6cd21574_3a1b3f9b380d45b8267613"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
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/D5gRVVHR-mjj998nIz5VtwQneUo>
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 16:12:00 -0000

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.

@martinthomson, that's another way to do it, but it makes me very nervous to say that we can't tell the difference between intent and a bug.  Seems like a door to a security risk or at least potential consistency concerns.  Consider a proxy whose back-end connection is interrupted and closes the stream before the entire payload has been transferred -- that error gets propagated and looks like a normal, intended response under those rules.

(Of course, if the proxy wrote a zero length and then had that happen, the same issue would exist.)

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