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

Mike Bishop <> Fri, 16 August 2019 17:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C4E4712009C for <>; Fri, 16 Aug 2019 10:18:08 -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=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wQzUtYsdbies for <>; Fri, 16 Aug 2019 10:18:07 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1EF0212008D for <>; Fri, 16 Aug 2019 10:18:07 -0700 (PDT)
Date: Fri, 16 Aug 2019 10:18:05 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1565975886; bh=dNBHus++59118w7SrIXkvLWQiAFnBwnrrV1Ap3+P4/I=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=VOqaHZEhlbxZnRuflXkkIOVZsH3TF1GvxBs/s94vIi7GqsBZxGLF0m6SO5PHQJAwN 9nLG5MWNtlwjQtA0v8t9cM4gQh0Mmg0JINqaALewOkeOKQ08XBEBRkMJ2QNHKIfahW PdS92v9H8OgH+sXhMxLFsgTNt+KYQnOOM9eZK93I=
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_5d56e54de86fc_721f3fedd64cd96c773db"; 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, 16 Aug 2019 17:18:09 -0000

Good question.  From a purely transactional point of view, if no part of the response depends on the remainder of the request, the client might as well stop sending.  However, I can also imagine an API where the server wants to consume and store the remainder of what the client is sending even if the return value is determined already.

The most generic way to handle this is to say that the server can express that it doesn't need the remainder of the response, and if it doesn't do so, the client SHOULD finish sending it.

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