[quicwg/base-drafts] Pushes "associated" with parent stream(s) (#3334)

Mike Bishop <notifications@github.com> Mon, 13 January 2020 17:03 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 BA2D812083C for <quic-issues@ietfa.amsl.com>; Mon, 13 Jan 2020 09:03:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Status: No, score=-8 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_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 PgVvfsYl1zY6 for <quic-issues@ietfa.amsl.com>; Mon, 13 Jan 2020 09:03:42 -0800 (PST)
Received: from out-6.smtp.github.com (out-6.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 27611120804 for <quic-issues@ietf.org>; Mon, 13 Jan 2020 09:03:42 -0800 (PST)
Date: Mon, 13 Jan 2020 09:03:41 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1578935021; bh=97X7gDXvQGvovlmka5x0xVrG9tkcFJCWYNiEAUGkW7c=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=fI54DD6JMA8U6FQTifIYltok+XHcFOwSYenaPeik9xCeObYGcIkiEwIj3B9b2jcYz 9EeaB4RQ7dwhPnzYcV97wCuIRzxgQ+728QsWzY8zCqmtAvWXtV/lygjcseCYw2lsH/ Yvdj0ZBodZkCp3nw1ax+lYl9s9MW/XFIZxgDOHxQ=
From: Mike Bishop <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2FYLH2ND7PU5N5ZNF4FHKW3EVBNHHCBOQJAU@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3334@github.com>
Subject: [quicwg/base-drafts] Pushes "associated" with parent stream(s) (#3334)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e1ca2ed5772a_1d9b3ff779acd9647665"; 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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/kyLb9RFCForL7FPAF0Rs6cN_gRM>
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: Mon, 13 Jan 2020 17:03:44 -0000

@RyanAtGoogle and I had an enlightening discussion on #3309, which highlighted a philosophical difference in our view of how push works, the filters through which we read RFC 7540, and the purpose of PUSH_PROMISE on multiple streams.  It might be worth expanding the text in HTTP/3 to give the reader the sense of both viewpoints, especially since disagreement between server and client implementations might have some sharp edges.

RFC 7540 says:
> Pushed responses are always associated with an explicit request from the client.  The PUSH_PROMISE frames sent by the server are sent on that explicit request's stream.

This "association" is only leveraged one other place in H2 directly; the push response is dependent on the associated stream for priority purposes.  What does it mean to be "associated"?

- One implementation path ignores it totally, keeping a global cache of pending pushes.  In this viewpoint, the purpose of PUSH_PROMISE on multiple streams is to make sure that *some* PUSH_PROMISE arrives before a reference to a resource that's being pushed, so the client knows it's already coming and can suppress requests.  Subsequent PUSH_PROMISEs are entirely superfluous.
- Another view says that pushes are tied to requests which are related, and might not be applicable to a request for that resource made in a different context (different navigations, different clients of a proxy, etc.); this is especially true if the response is not cacheable.  In this viewpoint, the purpose of PUSH_PROMISE/DUPLICATE_PUSH is to signal which request contexts the pushed response is applicable to.

These views are mostly identical if the response is cacheable or has appropriate Vary headers set, but they're subtly different views of the system.

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