IETF Logo Mail Archive

Re: RFC 7838 ALTSVC Frame

Cory Benfield <cory@lukasa.co.uk> Thu, 14 April 2016 09:43 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 AE0D212D9C9 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 14 Apr 2016 02:43:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.917
X-Spam-Level:
X-Spam-Status: No, score=-7.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lukasa-co-uk.20150623.gappssmtp.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 lrTFF3W6KHVB for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 14 Apr 2016 02:43:43 -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 0F60D12D6E0 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 14 Apr 2016 02:43:42 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1aqdjq-000727-7T for ietf-http-wg-dist@listhub.w3.org; Thu, 14 Apr 2016 09:39:02 +0000
Resent-Date: Thu, 14 Apr 2016 09:39:02 +0000
Resent-Message-Id: <E1aqdjq-000727-7T@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <cory@lukasa.co.uk>) id 1aqdjm-00071L-Kt for ietf-http-wg@listhub.w3.org; Thu, 14 Apr 2016 09:38:58 +0000
Received: from mail-wm0-f48.google.com ([74.125.82.48]) by maggie.w3.org with esmtps (TLS1.2:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from <cory@lukasa.co.uk>) id 1aqdjl-000763-5A for ietf-http-wg@w3.org; Thu, 14 Apr 2016 09:38:58 +0000
Received: by mail-wm0-f48.google.com with SMTP id n3so117230509wmn.0 for <ietf-http-wg@w3.org>; Thu, 14 Apr 2016 02:38:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lukasa-co-uk.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=+PkuGJNVHbbvJFOHQd1H47fr+yDMMgyMy2CKfYBqsVA=; b=iwe303G0P8d3TNSNdol4caRqNpzF2EYWEHqB+PcimMObT3fJxQpWoU1+Glo+4qn6in GlMs83MOCva8p4SiUE4ZTaMCwqYTOi/N9j0E9gE7O9uj2+71kiwkM77Ty9uJ0MQ5uF95 Ad+b3mT+8PDDA96J8mN5KoQ0qmLD39Fq/hKryKgi+H4oFDI9JUykZsHVbZtiG88HKO3A W4aSJtcKftaQJmiBB9lrBCxSOMfbga6UgWARHtp3jw8FhPzKH+MvvYgoCuFPzSm1Bt6Q SDfkgu9MA+kSiQzcwzpjaS7uhgKm2ERXYCVX5mMl7I+BrWSmWXvJ/kDfo2ye7KysGc5N uVeg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=+PkuGJNVHbbvJFOHQd1H47fr+yDMMgyMy2CKfYBqsVA=; b=eRIzogjQcAjgin+6KwubiqOJtIaTki+/VfN5PXQFd3xxLffGnkM7mC53qck/pFQT7e K0zqrfrbx+pSg1k5d1sTTFghbm+WVZjfKJVqLvRzgV8wiJIgNFKjzad125hQApWtMQya lrW0SJR8VQ4nM5OiO9Y/quQkv2Q8qEVsKYiJJl6FxN82/txuu8BVAEij/H/yUoUSqhEF VSqGi1ZTo5DiAhjeNbCbENyz4JwvGYF9Ja5weZ63HbKZoaqmHJ5F2xzn80LfehzPKLtt 7/9se/dbS0e2ss+1yzySzmvexLDY8iNzi0t1GLMyASGy0d6Q/WzTJP9a04Fr1p+h9HPN zthg==
X-Gm-Message-State: AOPr4FVTAdO1nIXWcv2VIi8VekeB/CCn5yQyNVuMNE8novDpQ6iQYyyC4wCymL4weuy9Sw==
X-Received: by 10.28.170.194 with SMTP id t185mr5186957wme.91.1460626710595; Thu, 14 Apr 2016 02:38:30 -0700 (PDT)
Received: from [192.168.1.6] (41.65.125.91.dyn.plus.net. [91.125.65.41]) by smtp.gmail.com with ESMTPSA id 188sm5619293wmk.6.2016.04.14.02.38.29 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 14 Apr 2016 02:38:29 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_6C9BADEB-638C-4319-AB08-362D591071A9"; protocol="application/pgp-signature"; micalg="pgp-sha256"
X-Pgp-Agent: GPGMail 2.6b2
From: Cory Benfield <cory@lukasa.co.uk>
In-Reply-To: <CABkgnnVTuAtOa1m8v-xqHdBUxM0w0-MkwcuRuwJfk_U_D7OX0g@mail.gmail.com>
Date: Thu, 14 Apr 2016 10:38:28 +0100
Cc: HTTP WG <ietf-http-wg@w3.org>
Message-Id: <F4C3A965-D05A-4663-8E5A-EE4746512067@lukasa.co.uk>
References: <BACC9A69-E230-49C4-B188-BA892C63C158@lukasa.co.uk> <CABkgnnVTuAtOa1m8v-xqHdBUxM0w0-MkwcuRuwJfk_U_D7OX0g@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
X-Mailer: Apple Mail (2.3124)
Received-SPF: pass client-ip=74.125.82.48; envelope-from=cory@lukasa.co.uk; helo=mail-wm0-f48.google.com
X-W3C-Hub-Spam-Status: No, score=-4.6
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1aqdjl-000763-5A dfd07fa026649049551a85d558ce1aa3
X-Original-To: ietf-http-wg@w3.org
Subject: Re: RFC 7838 ALTSVC Frame
Archived-At: <http://www.w3.org/mid/F4C3A965-D05A-4663-8E5A-EE4746512067@lukasa.co.uk>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/31454
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 14 Apr 2016, at 09:59, Martin Thomson <martin.thomson@gmail.com> wrote:
> 
> I can't speak to consensus, that will come with time, but physics
> dictates the frame has to be sent after the server receives the
> request (otherwise the server is advertising an alternative for an
> origin it can't guess about).  I would also hope that the stream isn't
> closed when the frame is sent, but I can't rely on physics to support
> that unfortunately.

So that suggests that the maximal set of stream states in which ALTSVC can be *sent* is open, reserved (local), half-closed (remote), half-closed (local), and closed().

Two follow-on questions then:

1. Do we have any reason to want to restrict that further? (e.g. ALTSVC in half-closed(local) feels a bit weird, but might be ok I guess?)
2. Do we feel comfortable having implementations just silently ignore ALTSVC in the other states? That’s in line with what we do for ALTSVC on stream 0 (which, if the origin field is not present, just gets silently ignored), but feels a bit annoying to me (silent failure is a bit sad).

Cory

v2.23.0 | Report a Bug | By Email