alt-svc and proxies

Piotr Galecki <piotr_galecki@affirmednetworks.com> Mon, 04 January 2016 03: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 388391B2A59 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 3 Jan 2016 19:37:35 -0800 (PST)
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 JDbfhw2DQrOj for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 3 Jan 2016 19:37:34 -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 E20261A88F7 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 3 Jan 2016 19:37:33 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1aFvtS-00018P-TT for ietf-http-wg-dist@listhub.w3.org; Mon, 04 Jan 2016 03:33:14 +0000
Resent-Date: Mon, 04 Jan 2016 03:33:14 +0000
Resent-Message-Id: <E1aFvtS-00018P-TT@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 <piotr_galecki@affirmednetworks.com>) id 1aFvtN-00017c-QZ for ietf-http-wg@listhub.w3.org; Mon, 04 Jan 2016 03:33:09 +0000
Received: from hub021-ca-4.exch021.serverdata.net ([64.78.22.171]) by maggie.w3.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <piotr_galecki@affirmednetworks.com>) id 1aFvtM-0001dk-A1 for ietf-http-wg@w3.org; Mon, 04 Jan 2016 03:33:09 +0000
Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-4.exch021.domain.local ([10.254.4.39]) with mapi id 14.03.0266.001; Sun, 3 Jan 2016 19:32:39 -0800
From: Piotr Galecki <piotr_galecki@affirmednetworks.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
Thread-Topic: alt-svc and proxies
Thread-Index: AQHRRqAd6t9qQxJyC0ajN3wfUaiTTQ==
Date: Mon, 04 Jan 2016 03:32:39 +0000
Message-ID: <2C515BE8694C6F4B9B6A578BCAC32E2F6D538FCC@MBX021-W3-CA-2.exch021.domain.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [74.104.133.106]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Received-SPF: pass client-ip=64.78.22.171; envelope-from=piotr_galecki@affirmednetworks.com; helo=hub021-ca-4.exch021.serverdata.net
X-W3C-Hub-Spam-Status: No, score=-4.6
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1aFvtM-0001dk-A1 f5296e4c67f16538529dabba1fd496cb
X-Original-To: ietf-http-wg@w3.org
Subject: alt-svc and proxies
Archived-At: <http://www.w3.org/mid/2C515BE8694C6F4B9B6A578BCAC32E2F6D538FCC@MBX021-W3-CA-2.exch021.domain.local>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/30846
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>

When reviewing the alt-svc draft it is not entirely clear to me from the draft how proxies should process Alt-Svc headers and
how they should behave when a response with the Alt-Svc header is received.
This should be defined.

IMO Alt-Svc header support should be required from proxies going forward.
Proxies should behave in the same/similar way as clients in respect to Alt-Svc headers.
They should cache information about alternative service available
and use the alt service for subsequent requests to origin.
Forward proxies supporting alternative services should also remove Alt-Svc headers
when forwarding a response to client.
This is because the protocol used for the client to proxy connection is defined (by user or WPAD) in proxy configuration settings
and it should not be modified by the alternative service header.

I'd like to propose the following changes:

- change "client" to "client (or intermediary)" in the text throughout the draft wherever appropriate

- possibly to section 2.4 or other add text:
  "Intermediaries when receiving a response with Alt-Svc header SHOULD cache the availability of the alternative service
   and use the alt service when forwarding subsequent requests to the origin,  provided the alternative service information is fresh.
   In order to continue using the user (or WPAD) configured protocol for the client to proxy connection
   forward proxies supporting alternative services SHOULD remove Alt-Svc header when forwarding a response to client."
 
Thanks,
Piotr