Return-Path: X-Original-To: quic-issues@ietfa.amsl.com Delivered-To: quic-issues@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA2D812083C for ; 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-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgVvfsYl1zY6 for ; Mon, 13 Jan 2020 09:03:42 -0800 (PST) Received: from out-6.smtp.github.com (out-6.smtp.github.com [192.30.252.197]) (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 ; 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 Reply-To: quicwg/base-drafts To: quicwg/base-drafts Cc: Subscribed Message-ID: 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: X-BeenThere: quic-issues@ietf.org 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: Mon, 13 Jan 2020 17:03:44 -0000 ----==_mimepart_5e1ca2ed5772a_1d9b3ff779acd9647665 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit @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: https://github.com/quicwg/base-drafts/issues/3334 ----==_mimepart_5e1ca2ed5772a_1d9b3ff779acd9647665 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

@RyanAtGoogle and I had an enlightening discussion on <= a class=3D"issue-link js-issue-link" data-error-text=3D"Failed to load is= sue title" data-id=3D"541069110" data-permission-text=3D"Issue title is p= rivate" data-url=3D"https://github.com/quicwg/base-drafts/issues/3309" da= ta-hovercard-type=3D"pull_request" data-hovercard-url=3D"/quicwg/base-dra= fts/pull/3309/hovercard" href=3D"https://github.com/quicwg/base-drafts/pu= ll/3309">#3309, which highlighted a philosophical difference in our v= iew of how push works, the filters through which we read RFC 7540, and th= e purpose of PUSH_PROMISE on multiple streams. It might be worth expandi= ng the text in HTTP/3 to give the reader the sense of both viewpoints, es= pecially since disagreement between server and client implementations mig= ht have some sharp edges.

RFC 7540 says:

Pushed responses are always associated with an explicit request from t= he client. The PUSH_PROMISE frames sent by the server are sent on that e= xplicit request's stream.

This "association" is only leveraged one other place in H2 directly; t= he push response is dependent on the associated stream for priority purpo= ses. 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 multi= ple streams is to make sure that some PUSH_PROMISE arrives befor= e 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 dif= ferent context (different navigations, different clients of a proxy, etc.= ); this is especially true if the response is not cacheable. In this vie= wpoint, the purpose of PUSH_PROMISE/DUPLICATE_PUSH is to signal which req= uest contexts the pushed response is applicable to.

These views are mostly identical if the response is cacheable or has a= ppropriate Vary headers set, but they're subtly different views of the sy= stem.

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, view it on GitHub, or unsubscribe.3D=

= ----==_mimepart_5e1ca2ed5772a_1d9b3ff779acd9647665--