RE: alt-svc and proxies

Piotr Galecki <> Tue, 05 January 2016 06:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E1CEF1B2B9A for <>; Mon, 4 Jan 2016 22:06:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.912
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KxppAiXWMdrn for <>; Mon, 4 Jan 2016 22:06:26 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D8AFF1B2B9D for <>; Mon, 4 Jan 2016 22:06:24 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1aGKhU-0007Yy-51 for; Tue, 05 Jan 2016 06:02:32 +0000
Resent-Date: Tue, 05 Jan 2016 06:02:32 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1aGKhP-0007Y6-Bj for; Tue, 05 Jan 2016 06:02:27 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <>) id 1aGKhN-0000Jt-Ah for; Tue, 05 Jan 2016 06:02:26 +0000
Received: from MBX021-W3-CA-2.exch021.domain.local ([]) by HUB021-CA-4.exch021.domain.local ([]) with mapi id 14.03.0266.001; Mon, 4 Jan 2016 22:01:56 -0800
From: Piotr Galecki <>
To: Martin Thomson <>
CC: HTTP Working Group <>
Thread-Topic: alt-svc and proxies
Thread-Index: AQHRRqAd6t9qQxJyC0ajN3wfUaiTTZ7rPvgAgAEp7Xk=
Date: Tue, 05 Jan 2016 06:01:55 +0000
Message-ID: <2C515BE8694C6F4B9B6A578BCAC32E2F6D53A153@MBX021-W3-CA-2.exch021.domain.local>
References: <2C515BE8694C6F4B9B6A578BCAC32E2F6D538FCC@MBX021-W3-CA-2.exch021.domain.local>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-5.4
X-W3C-Hub-Spam-Report: AWL=-0.817, BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1aGKhN-0000Jt-Ah 876a419788204764887f6c8b43391aff
Subject: RE: alt-svc and proxies
Archived-At: <>
X-Mailing-List: <> archive/latest/30848
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Yes, proxy is a client (and server) based on the definition you provided.
That clarifies it, thank you.

Even though it is not required Forward Proxy could still strip Alt-Svc header since the header has no use to user agent
and it could only have undesirable consequences if user-agent incorrectly implements alt services.

The draft does not clarify that origin server should be used for proxy selection.
Perhaps the following would make it more clear?
"A client SHOULD use origin, rather than alternative service, when evaluating configuration rules for proxy selection. If a proxy was selected for a given request the client SHOULD NOT directly connect to an alternative service for this request, but instead route it through that proxy."

From: Martin Thomson []
Sent: Sunday, January 03, 2016 10:50 PM
To: Piotr Galecki
Cc: HTTP Working Group
Subject: Re: alt-svc and proxies

We've discussed intermediation a lot on this list and concluded that
the current text was adequate.

A proxy in the sense you are concerned about is a client, as you can
see from

A proxy can forward Alt-Svc because clients that are configured to use
a proxy for a request will do so regardless of what they learn about
alternative services:

> A client configured to use a proxy for a given request SHOULD NOT directly connect to an alternative service for this request, but instead route it through that proxy.

On 4 January 2016 at 14:32, Piotr Galecki
<> wrote:
> 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