IETF Logo Mail Archive

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

Kazuho Oku <notifications@github.com> Wed, 27 November 2019 11:55 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 364F212088D for <quic-issues@ietfa.amsl.com>; Wed, 27 Nov 2019 03:55:39 -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 DDS4efXGYQYi for <quic-issues@ietfa.amsl.com>; Wed, 27 Nov 2019 03:55:37 -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 3BC6A120112 for <quic-issues@ietf.org>; Wed, 27 Nov 2019 03:55:37 -0800 (PST)
Received: from github-lowworker-cd7bc13.ac4-iad.github.net (github-lowworker-cd7bc13.ac4-iad.github.net [10.52.25.102]) by smtp.github.com (Postfix) with ESMTP id 2D6C0A0097 for <quic-issues@ietf.org>; Wed, 27 Nov 2019 03:55:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1574855736; bh=9xWcIEZqCHylUsOdkW75COGMzjfbsXoKJgvbdJwMV9o=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=J4jE0KAmQ2hhmmuDFheLDROg9mM7cZbdh9ZJdrDXI9poUfYpXsobuM1HYZkSCaC5K 3l32OYDucwq3zfdtUUjBxILYn7w2BOD6AF7XRMx5JPw2pInxhYvmnvu/Jiig7K+nTp jiBSUUA/a+0Es4boUt1T3y4SC89rowlBAIairczw=
Date: Wed, 27 Nov 2019 03:55:36 -0800
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4RCPAU7U5JOZRZ5LF35OLLREVBNHHB7DC6LI@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/559056999@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_5dde64381f6c0_4053fd6fb6cd95c141175"; 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/Ab3qE4JtPpbMOwcqEnJAm-C0qMc>
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:55:39 -0000

Note also that the current design has the priority inversion issue.

When the server sends a PUSH_PROMISE frame on request stream A, then sends a DUPLICATE_PUSH frame on stream B referring to the same pushed resource, and if stream B has higher precedence than stream A, then delivery of the request header of the pushed resource might get significantly delayed. Such a behavior would have negative effect on a well-designed client that blocks on the DUPLICATE_PUSH frame until it receives the request header of the pushed resource.

Sending the request headers on the pushed stream resolves the issue. The server can more easily control the priority of a pushed stream, it becomes much easier to send the request headers of a pushed response before anything else.

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

v2.31.3 | Report a Bug | By Email | System Status