Re: Stream State and PRIORITY Frames

Patrick McManus <pmcmanus@mozilla.com> Thu, 19 January 2017 15:55 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFA812963E for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 19 Jan 2017 07:55:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.359
X-Spam-Level:
X-Spam-Status: No, score=-9.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 wZHe1gXiBNEU for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 19 Jan 2017 07:55:05 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12AAE1296C4 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 19 Jan 2017 07:54:37 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cUF0h-0000XE-Is for ietf-http-wg-dist@listhub.w3.org; Thu, 19 Jan 2017 15:52:23 +0000
Resent-Date: Thu, 19 Jan 2017 15:52:23 +0000
Resent-Message-Id: <E1cUF0h-0000XE-Is@frink.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <pmcmanus@mozilla.com>) id 1cUF0e-0000W3-IE for ietf-http-wg@listhub.w3.org; Thu, 19 Jan 2017 15:52:20 +0000
Received: from www.ducksong.com ([192.155.95.102] helo=linode64.ducksong.com) by mimas.w3.org with esmtp (Exim 4.84_2) (envelope-from <pmcmanus@mozilla.com>) id 1cUF0Y-0006qT-5F for ietf-http-wg@w3.org; Thu, 19 Jan 2017 15:52:15 +0000
Received: from mail-yb0-f174.google.com (mail-yb0-f174.google.com [209.85.213.174]) by linode64.ducksong.com (Postfix) with ESMTPSA id 7F6603A0A9 for <ietf-http-wg@w3.org>; Thu, 19 Jan 2017 10:51:52 -0500 (EST)
Received: by mail-yb0-f174.google.com with SMTP id 123so23688219ybe.3 for <ietf-http-wg@w3.org>; Thu, 19 Jan 2017 07:51:52 -0800 (PST)
X-Gm-Message-State: AIkVDXL1Q0yiItgoBSXIIAY6pk4oqNxqAxy7xDfxnzjghbXFQTCXXpdvr4VRFLoPKCmnU4BIE8eL3DPqlyQ2ZQ==
X-Received: by 10.55.17.27 with SMTP id b27mr9212849qkh.200.1484841112400; Thu, 19 Jan 2017 07:51:52 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.162.65 with HTTP; Thu, 19 Jan 2017 07:51:51 -0800 (PST)
In-Reply-To: <2BC01E49-91A1-43A7-AFD0-5A34F2689428@lukasa.co.uk>
References: <CAFn2buAYWHQSWhhoKZ2GKbqXR1A+tScjkAwZmOuQ9gV9jMp2bA@mail.gmail.com> <CAGZNdJWe0Y=M_SWmgYabKbWZwPEuJdw67Km8+UtR4oUtZuXA5A@mail.gmail.com> <2BC01E49-91A1-43A7-AFD0-5A34F2689428@lukasa.co.uk>
From: Patrick McManus <pmcmanus@mozilla.com>
Date: Thu, 19 Jan 2017 10:51:51 -0500
X-Gmail-Original-Message-ID: <CAOdDvNq9RScN6-mP5o9hLgDTzMGhDL6pQ-vAMo8ZD6WK2Rf50w@mail.gmail.com>
Message-ID: <CAOdDvNq9RScN6-mP5o9hLgDTzMGhDL6pQ-vAMo8ZD6WK2Rf50w@mail.gmail.com>
To: Cory Benfield <cory@lukasa.co.uk>
Cc: Benedikt Christoph Wolters <benedikt.wolters@rwth-aachen.de>, Scott Mitchell <scott.k.mitch1@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="001a114740b60d7c2f054674834f"
Received-SPF: softfail client-ip=192.155.95.102; envelope-from=pmcmanus@mozilla.com; helo=linode64.ducksong.com
X-W3C-Hub-Spam-Status: No, score=-4.2
X-W3C-Hub-Spam-Report: AWL=-1.735, BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1cUF0Y-0006qT-5F 6b08bc9500e3134c5ec18b73ca9d2a8c
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Stream State and PRIORITY Frames
Archived-At: <http://www.w3.org/mid/CAOdDvNq9RScN6-mP5o9hLgDTzMGhDL6pQ-vAMo8ZD6WK2Rf50w@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33326
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On Tue, Jan 17, 2017 at 7:42 AM, Cory Benfield <cory@lukasa.co.uk> wrote:

>
> On 17 Jan 2017, at 08:38, Benedikt Christoph Wolters <
> benedikt.wolters@rwth-aachen.de> wrote:
>
> This question reminds me of a similiar issue we had a while ago at
> mitmproxy: https://github.com/mitmproxy/mitmproxy/issues/1498
>
> As far as I understand this, sending PRIORITY does not initiate a
> stream or change the stream state.
> HEADERS and PUSH_PROMISE initiate a stream. PRIORITY can be sent and
> received in any stream state.
>
>
> In fact, I think it’s the same issue. Scott linked to
> https://github.com/summerwind/h2spec/pull/67, which is referenced from
> and opened by the same person who opened https://github.com/h2o/
> h2o/pull/1136, which links to https://github.com/mitmprox
> y/mitmproxy/issues/1824, which is related to
> https://github.com/mitmproxy/mitmproxy/issues/1498 because both cases
> were sites deployed behind Fastly.
>
> For those who want background and don’t want to follow all those links,
> mitmproxy bumped into problems with sites deployed behind Fastly. mitmproxy
> encountered these because it was forwarding on traffic from Firefox, which
> would on connection-setup send a whole bunch of PRIORITY frames. hyper-h2
> (which powers mitmproxy’s HTTP/2 support) would allow this. h2o would not.
>
>
Hey Cory, this is a bit of a back alley - but can you help me understand
the scenario here. Priority is not an end to end concept - the dependencies
are clearly connection based and only make sense relevant to each other. So
is hyper-h2 just forwarding client Priority frames directly? How would that
work? (I know its not your project.. you just seem to grok what's going
on..)