IETF Logo Mail Archive

Re: RFC 7838 ALTSVC Frame

Martin Thomson <martin.thomson@gmail.com> Thu, 14 April 2016 09:49 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 185CE12D97A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 14 Apr 2016 02:49:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.017
X-Spam-Level:
X-Spam-Status: No, score=-8.017 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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=gmail.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 POgAQRXVhCOA for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 14 Apr 2016 02:49:41 -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 B961412D744 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 14 Apr 2016 02:49:41 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1aqdpc-0000h7-65 for ietf-http-wg-dist@listhub.w3.org; Thu, 14 Apr 2016 09:45:00 +0000
Resent-Date: Thu, 14 Apr 2016 09:45:00 +0000
Resent-Message-Id: <E1aqdpc-0000h7-65@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <martin.thomson@gmail.com>) id 1aqdpZ-0000gM-76 for ietf-http-wg@listhub.w3.org; Thu, 14 Apr 2016 09:44:57 +0000
Received: from mail-io0-f169.google.com ([209.85.223.169]) by lisa.w3.org with esmtps (TLS1.2:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from <martin.thomson@gmail.com>) id 1aqdpU-0003q1-KA for ietf-http-wg@w3.org; Thu, 14 Apr 2016 09:44:56 +0000
Received: by mail-io0-f169.google.com with SMTP id g185so98178637ioa.2 for <ietf-http-wg@w3.org>; Thu, 14 Apr 2016 02:44:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=GdnrsRZ3gfiqZu+13792c4XkXo2pn4MPvYKdfHD13Jg=; b=QAbNjL+gmyB3RjGdCflzmdEf77x9ZpjLMRgIxy1O7dEpeK8wIr2aN3pJ13iNKe5TaA X5bTQJ7d3gepoZ+Sknpzw1c6gh49MFJ3Yq1Cw4jJLPzOLiZNUbLyB+/3j0QIVKji+lK2 IiiCxxryGPMZcvqrqJ6plcet4z2SPTpyWzUZCp9T12FS+7AGw6eZMTg4gQchdJrBsuy8 YsEMmuh/8Yy+cRAaqWfaNuFAU2MxiqtIIjiHwVt/t/9xONCr4WYZhXbOGBxVA01oA86C 4WJHEjkD2tl6sDG6mw4ycEIqREYUPtuW9RvFy+PZb+5EF3be/6NeOC7fofPNa9Kg1Amw Z3ig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=GdnrsRZ3gfiqZu+13792c4XkXo2pn4MPvYKdfHD13Jg=; b=gQdbf8thcXfhWZgRA7coi3cGFTvjpo6n4BUhIaCG0ax5Fi4s4mU7bh7w/rsELvTZ1T SzgxL/1ccEM+3h2fFS0yllRD5S/WUvg0oNY/pAPNJr91aCy0TyNMcv2sZh0yjFx6CkmN /SIr+dvIv62AsCuQ5XaSGDViOFGhM2bHQisPhfAXzdBQIjlj62bJVYJupckvdRCFB0sG Dioldh7u9eZGx3cpLzPwwsh4fFL4XXWzU+onMbd3eP9VL9tQo0GF1T23B38H3Crpiu5/ 3x6zQKk/+k2t29wrSX1a7W1FrwO0BC5c9XgiXTRPsmZYb42mqYH3YTWokPerRFNMeQdO a7mA==
X-Gm-Message-State: AOPr4FUnf8gwQycLY3RJt6mQIDcIQu7H5GDk5Fa53fOWj5rbRFo1kOFln2iEDMMlCebFWL0ayM19vG8yqyJyPA==
MIME-Version: 1.0
X-Received: by 10.107.166.72 with SMTP id p69mr15487745ioe.100.1460627066780; Thu, 14 Apr 2016 02:44:26 -0700 (PDT)
Received: by 10.36.43.5 with HTTP; Thu, 14 Apr 2016 02:44:26 -0700 (PDT)
In-Reply-To: <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> <F4C3A965-D05A-4663-8E5A-EE4746512067@lukasa.co.uk>
Date: Thu, 14 Apr 2016 19:44:26 +1000
Message-ID: <CABkgnnVPoY+fpA5u+U1OpOFDVW2YzTHYaTnLjJoJ_zk7jC1w6Q@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Cory Benfield <cory@lukasa.co.uk>
Cc: HTTP WG <ietf-http-wg@w3.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=209.85.223.169; envelope-from=martin.thomson@gmail.com; helo=mail-io0-f169.google.com
X-W3C-Hub-Spam-Status: No, score=-7.9
X-W3C-Hub-Spam-Report: AWL=1.833, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: lisa.w3.org 1aqdpU-0003q1-KA c466f8cabb0e3e0ba76bcc73b435706c
X-Original-To: ietf-http-wg@w3.org
Subject: Re: RFC 7838 ALTSVC Frame
Archived-At: <http://www.w3.org/mid/CABkgnnVPoY+fpA5u+U1OpOFDVW2YzTHYaTnLjJoJ_zk7jC1w6Q@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/31455
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 April 2016 at 19:38, Cory Benfield <cory@lukasa.co.uk> wrote:
> 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?)

I assume that you mean sending in half-closed (local).  Well the main
reason for not sending after the response has been delivered is that
the client has probably lost all state.  In fact, I would suggest that
it probably isn't a good idea to send ALTSVC once you have completed
the HEADERS block for the response, because by then most clients move
to a completely different mode.

> 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).

Well, the cat is out of the bag now.  We didn't restrict the states
and now we have implicit permission to send any time.  Ignoring is
fine (since ignoring ALTSVC is always fine), so I guess we can only
recommend when is best to send to maximize the chance that clients
actually see the frame.

v2.23.0 | Report a Bug | By Email