Re: Alt-Svc related Chromium bug report (proxy related)

On 18 Apr 2014, at 8:22 am, Erik Nygren <erik@nygren.org> wrote:

> > "Proxies MUST NOT change or append Alt-Svc values."
> 
> Agreed.  I guess CDNs will need to remove Alt-Svc values that may be returned by an origin if they can't handle the upgrade.  This is a little unfortunate from a compatibility perspective.

Keep in mind that CDNs are *not* proxies as per the HTTP spec; they're gateways that happen to talk HTTP on the back end.


> It may also be worth us thinking through the Alt-Svc scenarios in the proxy world a little more carefully, perhaps with some concrete examples of flows to make sure we're on the same page.  For example, the upgrade case is fairly straight-forward:
> 
> 1) Upgrade to HTTP/2-over-TLS through a proxy:
> 
>         - client makes HTTP request through proxy (GET http://www.example.com/)
>         - server returns AltSvc to the client via the proxy (Alt-Svc: http2=443)
>         - client makes a HTTP connect request through the proxy (CONNECT www.example.com:443)
> 
> 
> However, some of the other cases are less clear to me:
> 
> 2) What happens for clients talking HTTP/2 to a proxy with the proxy talking HTTP/2 to the origin?  Would an ALTSVC frame referencing a different server and using TLS get passed through meaning that the client needs to now CONNECT through to do TLS?

I think the proxy would consume and potentially use the ALTSVC frame, since it's the one managing the connection to the server. Remember, ALTSVC doesn't change the origin.


> 3) What happens with clients talking HTTP/1 to a proxy when the proxy is talking HTTP/2 to the origin and gets an ALTSVC frame pointing to a different host?  Presumably the proxy needs to drop it?

Think so.

> 
> Are there other similar scenarios we need to work through?
> 
>       Erik
> 
> 
> 
> 
> 
> On Tue, Apr 1, 2014 at 8:32 PM, Mark Nottingham <mnot@mnot.net> wrote:
> I think that phrase probably needs to at least be modified to
> 
> "Proxies MUST NOT change or append Alt-Svc values."
> 
> 
> On 1 Apr 2014, at 2:51 pm, Martin Thomson <martin.thomson@gmail.com> wrote:
> 
> > On 31 March 2014 20:08, Amos Jeffries <squid3@treenet.co.nz> wrote:
> >> This is not "mis-advertising". The origin server producing the response
> >> eminently *does* support that service.
> >>
> >> I then draw your attention to draft-ietf-httpbis-alt-svc-00 section 3...
> >>
> >> " Intermediaries MUST NOT change or append Alt-Svc values. "
> >>
> >> There is no distinction regarding intermediary type(s), nor exemption
> >> clauses. CDN is an intermediary just as much as any other.
> >
> >
> > That would be fine, except for the fact that - in this case - it seems
> > likely that the CDN is acting as an origin server that serves a copy
> > of the content, not an intermediary.  The URI includes the domain name
> > of the CDN.  Will, amirite?
> >
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
> 
> 
> 

--
Mark Nottingham   http://www.mnot.net/

Received on Sunday, 20 April 2014 00:03:32 UTC