Re: [quicwg/base-drafts] What if server does not send HTTP_EARLY_RESPONSE but starts sending response (#2963)

Mike Bishop <> Mon, 07 October 2019 17:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6DD3512010F for <>; Mon, 7 Oct 2019 10:40:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.382
X-Spam-Status: No, score=-6.382 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_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W-zlQURrAT5s for <>; Mon, 7 Oct 2019 10:40:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7BF07120882 for <>; Mon, 7 Oct 2019 10:32:14 -0700 (PDT)
Date: Mon, 07 Oct 2019 10:32:13 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1570469533; bh=AVkt8RgAvTG62etn2XWT+O01V6AXZqZ4haZWSM9HQeA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=QBEsPshCFyTtb9w90Is63+FYpPPSfwrliahR6tmBiYjMCzrL1uauaZBsi0p4pvrQO X+ikGclThYSHLwJukJtRNSht8AkOVkLYlO5qHZArLoMz80GY05GYIdrWv+++BWWhqv WRYNYFxTFPsWbW6AaqWyq+3A8GnkBnaA/WHqOCGY=
From: Mike Bishop <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/2963/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] What if server does not send HTTP_EARLY_RESPONSE but starts sending response (#2963)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d9b769d8afae_487a3fc6130cd960148112"; 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
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 07 Oct 2019 17:40:34 -0000

Another potential case where the server would want to keep the client sending is where the server is performing some transformation (compress/decompress, transcode, en/decrypt, etc.) on the data sent by the client, and is doing the conversion in blocks as bytes are received rather than storing the full resource locally.

The same recommendation stands -- unless the server exercises the option to tell the client to stop, the usual rules apply that the client needs to fully send the request to get a full response.  Do we need text for this?  I'd think that's already the default position.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: