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

Kazuho Oku <notifications@github.com> Thu, 28 November 2019 00:13 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 50314120BA5 for <quic-issues@ietfa.amsl.com>; Wed, 27 Nov 2019 16:13:45 -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 yL2ShESZfukH for <quic-issues@ietfa.amsl.com>; Wed, 27 Nov 2019 16:13:42 -0800 (PST)
Received: from out-21.smtp.github.com (out-21.smtp.github.com [192.30.252.204]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 652FA120BBE for <quic-issues@ietf.org>; Wed, 27 Nov 2019 16:13:42 -0800 (PST)
Date: Wed, 27 Nov 2019 16:13:41 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1574900021; bh=DjKakhLkN19Fi4mtF7o+ZvOzHcsEyb9boWKzZNkiOwo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ADhBmHIQ3HhLNmXe/Xd3tanGaqJ0mfdLmj3Ik+wCc0aB9FWhEZYn7l74cVE0bTIsw VSLCF1n70Ik9oySFEYUTNBnWZR30O/6IYIFxHgW+EN2YTAj4JBkM6Ff9TMdPMcLgzT 2iAALcf7YBVWOlrm8bp6pC0lroVhzue3p/4eB1AQ=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2HY2XQUWRCFOYC4O535RB3LEVBNHHB7DC6LI@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/559292834@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_5ddf1135574ee_197e3feae16cd96c4255d2"; 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/op4q-uEQnN67Gz0T6cZo6Gv7Hjo>
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: Thu, 28 Nov 2019 00:13:45 -0000

@LPardue @martinthomson Apologies for not chiming in to the discussion in #1864.

@martinthomson 
> One advantage of the current design is the ability to exercise flexibility. There is nothing preventing someone from pushing the same thing twice in this design, thereby avoiding DUPLICATE_PUSH.

I do not think that is something that a server should do, as it would mean that the server would be pushing not only the headers but the entire response multiple times to the client.

@RyanAtGoogle 
> 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)

+1

I can see @martinthomson's view that push is feature that the server might use, and therefore that it can be complicated. But as the number of traps increases in the protocol, it becomes more likely that some stacks (or some combination of client- and server-side stacks) would have edge cases that lead to worse performance when push is used.

In HTTP/2, push is a feature that is often misused, leading to performance degradation, even though the protocol itself is designed correctly. The situation would become worse in HTTP/3, if we introduce uncertain behaviors to the protocol design (i.e., some clients might not block on DUPLICATE_PUSH).

-- 
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-559292834