W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2016

RE: alt-svc and proxies

From: Piotr Galecki <piotr_galecki@affirmednetworks.com>
Date: Tue, 5 Jan 2016 06:01:55 +0000
To: Martin Thomson <martin.thomson@gmail.com>
CC: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <2C515BE8694C6F4B9B6A578BCAC32E2F6D53A153@MBX021-W3-CA-2.exch021.domain.local>
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 [martin.thomson@gmail.com]
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 https://httpwg.github.io/specs/rfc7230.html#operation

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.
-- https://httpwg.github.io/http-extensions/alt-svc.html#switching

On 4 January 2016 at 14:32, Piotr Galecki
<piotr_galecki@affirmednetworks.com> 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
Received on Tuesday, 5 January 2016 06:02:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 22 March 2016 12:47:10 UTC