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

Dragana Damjanovic <notifications@github.com> Fri, 09 August 2019 15:36 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 9491A12007A for <quic-issues@ietfa.amsl.com>; Fri, 9 Aug 2019 08:36:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Status: No, score=-6.596 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_28=1.404, 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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id p_hQv3EGLzNL for <quic-issues@ietfa.amsl.com>; Fri, 9 Aug 2019 08:36:02 -0700 (PDT)
Received: from out-17.smtp.github.com (out-17.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93554120019 for <quic-issues@ietf.org>; Fri, 9 Aug 2019 08:36:02 -0700 (PDT)
Date: Fri, 09 Aug 2019 08:36:01 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1565364961; bh=Zd/UFBsm7cu6OLmLMbqFdjspKSHRiGPrnnqahrj0pjg=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=POQ9bH+Nsh4ynCdLL96XkgLEIrKdt2GBk5LaQowT+l6G8zxJzcLXCM45Z93Meo5cw 66P/4554BYx3Vqpif98k+k9KtwNBK1Iec1xjDaHvx9m9lSA4J9REGnBK7C6UOs3ZEc fGj7rK8KYtydUci4QNya0oKyywG7IXjiSRKULnbU=
From: Dragana Damjanovic <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK3DVC3KNX7JEMDCT4F3LLCWDEVBNHHBZDNRFQ@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2963@github.com>
Subject: [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_5d4d92e1b3142_566e3fcef50cd95c158146"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ddragana
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/ww27JKgRDaC5rDtUf4_2RfhHRbs>
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, 09 Aug 2019 15:36:05 -0000

There is a text that say:

> A server can send a complete response prior to the client sending an
>    entire request if the response does not depend on any portion of the
>    request that has not been sent and received.  When this is true, a
>    server MAY request that the client abort transmission of a request
>    without error by triggering a QUIC STOP_SENDING frame with error code
>    HTTP_EARLY_RESPONSE, sending a complete response, and cleanly closing
>    its stream.  Clients MUST NOT discard complete responses as a result
>    of having their request terminated abruptly, though clients can
>    always discard responses at their discretion for other reasons.

A server MAY send STOP_SENDING. What should the client do if the server does not send it? Is the client allowed to close the send stream or should it continue until everything has been sent? In the second case the client may receive the complete response before the complete request has been sent. Is there a use case where a sever can send a response before receiving the complete request, but still cares about the request data?

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