Re: Design Issue: PUSH_PROMISE and Stream Priority
Roberto Peon <grmocg@gmail.com> Sat, 27 April 2013 21:29 UTC
Return-Path: <ietf-http-wg-request@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 E870321F968D for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 27 Apr 2013 14:29:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRjEAHUGPNj5 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 27 Apr 2013 14:29:37 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0ECD821F9682 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sat, 27 Apr 2013 14:29:37 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UWCfU-0008Df-2X for ietf-http-wg-dist@listhub.w3.org; Sat, 27 Apr 2013 21:28:28 +0000
Resent-Date: Sat, 27 Apr 2013 21:28:28 +0000
Resent-Message-Id: <E1UWCfU-0008Df-2X@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1UWCfP-0008Cv-3L for ietf-http-wg@listhub.w3.org; Sat, 27 Apr 2013 21:28:23 +0000
Received: from mail-ob0-f178.google.com ([209.85.214.178]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1UWCfO-0002yh-Ci for ietf-http-wg@w3.org; Sat, 27 Apr 2013 21:28:23 +0000
Received: by mail-ob0-f178.google.com with SMTP id 16so4494398obc.37 for <ietf-http-wg@w3.org>; Sat, 27 Apr 2013 14:27:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=akyOK4Jg/sx93PUhamRBDAPIWD/Ir5Z9eP6o2e+gL3A=; b=gOHO7S1FHpCnvk6m5ofSFtMjmezZ2TvKYGAct9JRc00A3gSY4kFEg/XH6R0w1REA9i Oi6OJ0QFzSEWENxigCvv0w3F/PpH1wQ2mb9UUTdCXsim/b9KsTrARmUkKlRn8H2x/B8m 1/6QLUlJPGz6vHTOr7LN8dyScqh9RErMrnKon9PWmOUwWwnDKnmfir1JsYT4wwtCdCvf C6uyeZPDJCAUcapk6GpqkFb09wnDKqn+I+8Prnf1Re8ONnL61xmTSicNjqP3bYtUvMwO absFyGFvsY4jHMr1FpLT+Lt9uCTBheziBq4yA6lFQBXDMM1PmuaHp/UOqqAJ6pcIVdMe TmuA==
MIME-Version: 1.0
X-Received: by 10.60.141.35 with SMTP id rl3mr26347161oeb.121.1367098076507; Sat, 27 Apr 2013 14:27:56 -0700 (PDT)
Received: by 10.76.12.103 with HTTP; Sat, 27 Apr 2013 14:27:56 -0700 (PDT)
In-Reply-To: <CABP7RbeMmCCVHPT5XxiTbrrRs4QBGeQfvMY1_YLasvpZnJMCYA@mail.gmail.com>
References: <CABP7Rbf_hZ036vUs4LNTrGQ91kft2_97aV-9Gi2KVJnUJphbNA@mail.gmail.com> <CABkgnnUBEvDtNQM8G5vyfyqRz4tQ8su9+14gMTdaXhzY2cq+Kg@mail.gmail.com> <CABP7RbccA=Zo2NVzJJ-8-G+y2cNt_j8rLr5YVfB_7CVOXLE_JQ@mail.gmail.com> <CABkgnnV64vRPcrdYGFcJQGZW_Wud5fKT76_z5BJc0NndsAEGYg@mail.gmail.com> <6C71876BDCCD01488E70A2399529D5E516416AC5@ADELE.crf.canon.fr> <CABP7RbcCesHYf8Q-9j22yg9=GGJWUooKKwBbJhBiyALzx3jWnw@mail.gmail.com> <CABkgnnVoc_s+x2Qu5HZz+OwkQaHhnNM57iYCLVH-QQO+g7vH7A@mail.gmail.com> <CAP+FsNff96XihwzftWyp+B5givEUF5kqLA=qFd+=VjBG7P-OhA@mail.gmail.com> <CABP7RbeMmCCVHPT5XxiTbrrRs4QBGeQfvMY1_YLasvpZnJMCYA@mail.gmail.com>
Date: Sat, 27 Apr 2013 14:27:56 -0700
Message-ID: <CAP+FsNepmuRb9ZaKa_zJiPfTJD_4VvX5RYos4RZvbBSaFjYV5g@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: James M Snell <jasnell@gmail.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, RUELLAN Herve <Herve.Ruellan@crf.canon.fr>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="047d7b339dbb3982f904db5e538f"
Received-SPF: pass client-ip=209.85.214.178; envelope-from=grmocg@gmail.com; helo=mail-ob0-f178.google.com
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=-1.735, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UWCfO-0002yh-Ci 81c00feb4b2d8509fe55402a315d2597
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Design Issue: PUSH_PROMISE and Stream Priority
Archived-At: <http://www.w3.org/mid/CAP+FsNepmuRb9ZaKa_zJiPfTJD_4VvX5RYos4RZvbBSaFjYV5g@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17636
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>
Sending of a message including a priority field != setting a priority. Server pushed streams have priority, but they are most likely to be set by the client. I was understanding that we were asking a separate question: If it was worthwhile to have the server announce what priority it decided to use for a pushed stream, and if so... when (e.g. at PUSH_PROMISE time, or, when doing HEADERS). -=R On Sat, Apr 27, 2013 at 1:30 PM, James M Snell <jasnell@gmail.com> wrote: > I honestly cannot imagine any scenario where it would be useful or > desirable to allow the server to set a priority for pushed streams. My > preference would be for us to say that only client-initiated streams > have a priority. If we want to leave the door open later on, we can > say that priority on server-initiated streams is undefined and out of > scope rather than saying it's not allowed at all. > > On Fri, Apr 26, 2013 at 11:46 AM, Roberto Peon <grmocg@gmail.com> wrote: > > Sorry I'm so slow-- internet connectivity is absolutely crud where I am > > right now. > > > > What will the client do with the information a push_promise? > > The headers, etc. are obvious-- > > That data will prevent the client from creating another (redundant) > request > > for the resource/ > > If the client is given priority information with a push_promose, perhaps > > this might cause the client to send a reprio message immediately to > whatever > > the client wants, potentially before the server begins sending bytes or > > creates the stream/reads the bytes. This assumes that the server even > > *knows* what the priority is at that point, which it may not. > > > > ... and, really, that is the only thing I can see the client doing with > that > > information. Does anyone see anything else it might do with it? > > > > does anyone think this is likely to be useful? > > > > > > > > On Fri, Apr 26, 2013 at 11:35 AM, Martin Thomson < > martin.thomson@gmail.com> > > wrote: > >> > >> On 26 April 2013 09:27, James M Snell <jasnell@gmail.com> wrote: > >> > For this there are several possible solutions: > >> > > >> > A. We can simply say PUSH_PROMISE streams have no priority. > >> > B. We can say that PUSH_PROMISE streams inherit the priority of > >> > their parent, client-initiated stream > >> > C. We can allow the server to use HEADERS+PRIORITY or a new > >> > Reprioritization Frame to establish the priority of a pushed stream. > >> > >> That seems like a fair taxonomy. > >> > >> A is not possible. There is no such thing as no priority. Default > >> priority, perhaps. At the point that you have to contend with > >> choosing between two streams, then you have prioritization. > >> > > >
- Design Issue: PUSH_PROMISE and Stream Priority James M Snell
- Re: Design Issue: PUSH_PROMISE and Stream Priority Martin Thomson
- Re: Design Issue: PUSH_PROMISE and Stream Priority James M Snell
- Re: Design Issue: PUSH_PROMISE and Stream Priority Martin Thomson
- Re: Design Issue: PUSH_PROMISE and Stream Priority Roberto Peon
- Re: Design Issue: PUSH_PROMISE and Stream Priority William Chan (ιζΊζ)
- Re: Design Issue: PUSH_PROMISE and Stream Priority James M Snell
- RE: Design Issue: PUSH_PROMISE and Stream Priority RUELLAN Herve
- RE: Design Issue: PUSH_PROMISE and Stream Priority RUELLAN Herve
- Re: Design Issue: PUSH_PROMISE and Stream Priority Patrick McManus
- Re: Design Issue: PUSH_PROMISE and Stream Priority James M Snell
- Re: Design Issue: PUSH_PROMISE and Stream Priority Martin Thomson
- Re: Design Issue: PUSH_PROMISE and Stream Priority Roberto Peon
- Re: Design Issue: PUSH_PROMISE and Stream Priority James M Snell
- Re: Design Issue: PUSH_PROMISE and Stream Priority Roberto Peon
- Re: Design Issue: PUSH_PROMISE and Stream Priority James M Snell
- Re: Design Issue: PUSH_PROMISE and Stream Priority Roberto Peon
- Re: Design Issue: PUSH_PROMISE and Stream Priority James M Snell