[quicwg/base-drafts] Rationalise Server-Push-specific rejection error codes (#2812)

Lucas Pardue <notifications@github.com> Wed, 19 June 2019 11:00 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 D3B83120226 for <quic-issues@ietfa.amsl.com>; Wed, 19 Jun 2019 04:00:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.605
X-Spam-Status: No, score=-6.605 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_DKIMWL_WL_HIGH=-0.01] 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 4HPLGmFGelgJ for <quic-issues@ietfa.amsl.com>; Wed, 19 Jun 2019 04:00:43 -0700 (PDT)
Received: from out-19.smtp.github.com (out-19.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 CBB38120099 for <quic-issues@ietf.org>; Wed, 19 Jun 2019 04:00:42 -0700 (PDT)
Date: Wed, 19 Jun 2019 04:00:41 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1560942041; bh=aOpvSVucNr9wxnxVAtiHtUkUeu6XyOqCgI7wxi0NzvM=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=NDfx3QN+xd2jYszhscKtESXiP1+uSUKtLmDwZ37nGRyZRVFddpVaBGnzgGuaCxrWA tT5rx+uisd8LErNFIrmlQroHJrLftw5cUG3g7dXIXPXcVgnO8Vm0wDC+OBFgDWH8ik X9pEjEBzvaIsv2qrb7qWjus/NRxMZP8yP5x8iHoo=
From: Lucas Pardue <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK73CRKGCCNWUYYV67F3C5EFTEVBNHHBWS5T3I@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2812@github.com>
Subject: [quicwg/base-drafts] Rationalise Server-Push-specific rejection error codes (#2812)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d0a15d995f29_1f8c3fa88aacd95c18044c"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: LPardue
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/EHQuS2kUf84Oqn_wMM1geuC7PCk>
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: Wed, 19 Jun 2019 11:00:45 -0000

RFC 7540 section 8.2.2 states:

>   If the client determines, for any reason, that it does not wish to
   receive the pushed response from the server or if the server takes
   too long to begin sending the promised response, the client can send
   a RST_STREAM frame, using either the CANCEL or REFUSED_STREAM code
   and referencing the pushed stream's identifier.

HTTP/3 changed push a bit and introduced two error codes: HTTP_PUSH_REFUSED and HTTP_PUSH_ALREADY_IN_CACHE. These is extra fidelity on top of HTTP/2, clearly articulating if the pushed item is in cache or not. This may be seen as useful, however there are some practical downsides:

* The CANCEL_PUSH frame exists and is the first RECOMMENDED action for declining a push. This does not expose the reason
* In actuality, server push caching is murky, which may affect the amount of confidence an operator could put into analyising these error codes.

I think it is simpler, more self-consistent, and mroe HTTP/2-consistent to have one error code for server push. I'll prepare a PR for this.

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