[quicwg/base-drafts] Why are there two ways of associating push with requests? (#3275)

Kazuho Oku <notifications@github.com> Wed, 27 November 2019 11:39 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 DAF631208A2 for <quic-issues@ietfa.amsl.com>; Wed, 27 Nov 2019 03:39:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Status: No, score=-7.999 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_32=0.001, 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 E8P0u8_bRwI8 for <quic-issues@ietfa.amsl.com>; Wed, 27 Nov 2019 03:39:51 -0800 (PST)
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 2FB42120870 for <quic-issues@ietf.org>; Wed, 27 Nov 2019 03:39:51 -0800 (PST)
Date: Wed, 27 Nov 2019 03:39:49 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1574854789; bh=jfg9hhd17kzsT5daY4xBnE+ZEGe7y+JuL0EPYcaUj3U=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=gP+DxvgQV7eytmU35Ye7TJO1Cdioa7GQ7IcNfqH//ojc4ZKxzisoJ5Gio0jcRsNF7 c1yquvX5nggpozlP0eSR0sSqqtm/TNASTMMZSJkUjSpvcEXwZLBtHRmm7VN0h5WvmY 9q/tMUm5QMB0RBdFS8FpqOmbHBSTurrlAOl2i7Pg=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZOXRDTR4BKB2UH5JV35OJQLEVBNHHB7DC6LI@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3275@github.com>
Subject: [quicwg/base-drafts] Why are there two ways of associating push with requests? (#3275)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5dde60857dcff_71843fcb94ccd964479c6"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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/TbaARbDX3Pa-AFbVVqj6V0k22l4>
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, 27 Nov 2019 11:39:54 -0000

At the moment, the HTTP draft defines two ways of associating a pushed response with requests. One of the requests being associated uses PUSH_PROMISE, while other requests use DUPLICATE_PUSH when referring to the same pushed response.

This seems like an unnecessary complexity to me.

I wonder if we can use the following design instead:
* Send the *request of a push* on the "push stream," instead of sending it using PUSH_PROMISE.
* Merge PUSH_PROMISE and DUPLICATE_PUSH into one frame. The unified frame type would carry the PUSH_ID only.
* (Optionally) change PUSH_ID to stream ID.

I think that such change would simplify the client-side code, as there would no longer be two different logic for associating a push with a request. On the server-side, the change would also simplify the code, assuming that the server uses DUPLICATE_PUSH. My intuition that servers should be using that to avoid pushing the same resource twice on a single connection.

The argument against making such change would be that there would be no guarantee that the pushed URL would be available to the client before the client discovers the use of that pushed URL. However, in the current state, that guarantee exists only when the PUSH_PROMISE frame is being used, but not when DUPLICATE_PUSH is used. Considering that, I am doubtful if having something that *occasionally* works is worth the complexity.

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