Re: #44: alt-svc frame on pushed streams

Mark Nottingham <mnot@mnot.net> Sun, 22 March 2015 16:37 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 (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA16B1AC3D6 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 22 Mar 2015 09:37:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level:
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 tQPDU3t4_cSt for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 22 Mar 2015 09:37:21 -0700 (PDT)
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 4AA4C1A0211 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 22 Mar 2015 09:37:21 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1YZioV-0004tb-Mx for ietf-http-wg-dist@listhub.w3.org; Sun, 22 Mar 2015 16:33:23 +0000
Resent-Date: Sun, 22 Mar 2015 16:33:23 +0000
Resent-Message-Id: <E1YZioV-0004tb-Mx@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.80) (envelope-from <mnot@mnot.net>) id 1YZioP-0004rO-6O for ietf-http-wg@listhub.w3.org; Sun, 22 Mar 2015 16:33:17 +0000
Received: from mxout-07.mxes.net ([216.86.168.182]) by maggie.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1YZioO-0002UP-1n for ietf-http-wg@w3.org; Sun, 22 Mar 2015 16:33:17 +0000
Received: from dhcp-b0ef.meeting.ietf.org (unknown [31.133.176.239]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0F1C922E200; Sun, 22 Mar 2015 12:32:51 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <CAOdDvNotmQa2vSU-BebgynG2cx1UGZN50NnyNSzxGQ_0MnVSqA@mail.gmail.com>
Date: Sun, 22 Mar 2015 11:32:51 -0500
Cc: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <38827246-43D7-425C-B841-D15252847110@mnot.net>
References: <2A565EA2-D713-478F-A771-C08202657EC2@mnot.net> <CABkgnnVQPQqpZR85a1k=zX4kt6yETzxKqqk8nJbcc0K8mo9w7A@mail.gmail.com> <CAOdDvNotmQa2vSU-BebgynG2cx1UGZN50NnyNSzxGQ_0MnVSqA@mail.gmail.com>
To: Patrick McManus <mcmanus@ducksong.com>
X-Mailer: Apple Mail (2.2070.6)
Received-SPF: pass client-ip=216.86.168.182; envelope-from=mnot@mnot.net; helo=mxout-07.mxes.net
X-W3C-Hub-Spam-Status: No, score=-6.8
X-W3C-Hub-Spam-Report: AWL=-0.055, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, W3C_AA=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1YZioO-0002UP-1n 1f912dba7e55a5ca6d785221e3a7278a
X-Original-To: ietf-http-wg@w3.org
Subject: Re: #44: alt-svc frame on pushed streams
Archived-At: <http://www.w3.org/mid/38827246-43D7-425C-B841-D15252847110@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/29010
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>

So, I think we could solve Patrick’s issue by saying:

"""
An ALTSVC frame on a client-initiated stream containing non-empty "Origin" information is invalid and must be ignored. Likewise, an ALTSVC frame on stream 0 with empty (length 0) "Origin" information is invalid and must be ignored.
"""

to:

"""
An ALTSVC frame on stream 0 with empty (length 0) "Origin" information is invalid and must be ignored. An ALTSVC frame on a stream other than stream 0 containing non-empty "Origin" information is invalid and must be ignored. 
"""

WRT Julian's issue, I think we could address this by changing 

"""
An ALTSVC frame from a server to a client on a client-initiated stream indicates that the conveyed alternative service is associated with the origin of that stream.
"""

to:

"""
An ALTSVC frame from a server to a client on a stream other than stream 0 indicates that the conveyed alternative service is associated with the origin of that stream.
"""

Both of these assume that we want to allow ALTSVC on a pushed stream.

Discuss...



> On 17 Mar 2015, at 12:21 pm, Patrick McManus <mcmanus@ducksong.com> wrote:
> 
> Issue 44, which I raised, is specifically about the interpretation of the origin field for pushed streams. The document already sepcifies must ignore ignore the frame for pulled streams which specify an origin (because the stream ID is supposed to define the origin) but it is silent about pushed streams. I suggested must ignore for pushed streams too (when they provide an origin) which still makes sense to me (i.e. as martin says, they aren't special.)
> 
> Julian added onto the issue saying we don't specify altsvc frame handling in general (not just origin semantics) for pushed frames. Mark seems to have coalesced those two points into this one email - I agree that the answer for the whole frame shouldn't be must ignore assuming it doesn't supply an origin.
> 
> at least that's the way I unwind it.
> 
> 
> 
> On Tue, Mar 17, 2015 at 12:41 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> On 16 March 2015 at 22:50, Mark Nottingham <mnot@mnot.net> wrote:
> > Any objection to stating that they MUST be ignored by recipients?
> 
> Is there any reason that server-initiated streams need to be made
> special?  I mean, once the standard response handling has started, I
> can't imagine any reason for treating push specially.
> 
> 

--
Mark Nottingham   https://www.mnot.net/