IETF Logo Mail Archive

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

Ryan Hamilton <notifications@github.com> Wed, 27 November 2019 23:01 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C11D7120AF1 for <quic-issues@ietfa.amsl.com>; Wed, 27 Nov 2019 15:01:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.382
X-Spam-Level:
X-Spam-Status: No, score=-6.382 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_24=1.618, 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 87E2eUdTGB2m for <quic-issues@ietfa.amsl.com>; Wed, 27 Nov 2019 15:01:51 -0800 (PST)
Received: from out-19.smtp.github.com (out-19.smtp.github.com [192.30.252.202]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0163D120A58 for <quic-issues@ietf.org>; Wed, 27 Nov 2019 15:01:50 -0800 (PST)
Date: Wed, 27 Nov 2019 15:01:50 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1574895710; bh=BWdos8iOfQQgA7MNlGZimxAQzo3OXQWS4Y1lvlx2eJM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Tt0pX6PQSdaIS5io7v7DY/a9O9/HDbRmEDkrbK8/TPDebpxQSzOihMv4U4/dcNoUw u56IE456uXfwxi40lopa8m2Xzh8uyAiBAqcmYDU0NlgyjgyVRTTj22TmG8eZOVyMyD upTPftbWMCJCuoxLUCtUpUuaw1xNpqVWOeoNNgWk=
From: Ryan Hamilton <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK6JDP4Q7IGVTUK2AMV35QZN5EVBNHHB7DC6LI@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/559279217@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3275@github.com>
References: <quicwg/base-drafts/issues/3275@github.com>
Subject: Re: [quicwg/base-drafts] Why are there two ways of associating push with requests? (#3275)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ddf005e22693_75083fa81cacd95c352184"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: RyanAtGoogle
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/FH2L6lNZIlmaqany9pvyghrIzhI>
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 23:01:53 -0000

I agree that there's no new information here; I just really dislike the sharp edge of the current DUPLICATE_PUSH behavior:

>  In that case, the simplest course is to proceed as though no push were promised until the PUSH_PROMISE arrives.

Indeed, that is the simplest course. But unless all user-agents do the same thing it means that servers can't rely on particular client-side behavior which is a real bummer. Push is already hard enough to get right (in both clients and servers) it seems like adding more rough edges runs the risk of resulting in push being disabled/removed from some implementations. (I believe Brad Lassey from Chrome presented at IETF 102 data which suggested doing exactly this)

-- 
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/3275#issuecomment-559279217

v2.23.0 | Report a Bug | By Email