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

Mike Bishop <> Fri, 18 October 2019 18:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F1E8012022E for <>; Fri, 18 Oct 2019 11:11:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.381
X-Spam-Status: No, score=-6.381 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tIESy9ZWFZdR for <>; Fri, 18 Oct 2019 11:11:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8E0931208DA for <>; Fri, 18 Oct 2019 11:11:32 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 99E7C5210C2 for <>; Fri, 18 Oct 2019 11:11:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1571422291; bh=kgdpehvumNYaAIatpIPE3UsTgtNfjVnpGcY9BxO2E+Y=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=lXvhE8T85wZP/g8sG3eYN4/bira7WSssXZ6rXKMwAdm6+i6BXxlZ/NiICy0Cvl/Qd soMQmFqQzKGL47KYb3ec16LDHakU6ts3r7jxhTju2sxUeTXMxcZJG/TNjPSK07ios9 o+FL3qKRr4btLAkzgaPnU0VMnufVaATXAwFVq0q0=
Date: Fri, 18 Oct 2019 11:11:31 -0700
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_5daa00538b340_64b93fe54aecd960497a9"; 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: Fri, 18 Oct 2019 18:11:43 -0000

http-core [says](
> A server that responds with a final status code before reading the entire request payload body SHOULD indicate whether it intends to close the connection (see Section 9.7 of [Messaging]) or continue reading the payload body. 

I think the resolution here is to explicitly map STOP_SENDING(EARLY_RESPONSE) to the indication that it intends the stream to be fully closed after the response, and the absence of STOP_SENDING to the server's intent to continue reading the payload body.

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