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

RE: draft-ietf-httpbis-alt-svc-12.txt

From: Mike Bishop <Michael.Bishop@microsoft.com>
Date: Thu, 11 Feb 2016 05:11:51 +0000
To: Amos Jeffries <squid3@treenet.co.nz>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <CY1PR03MB137422D6387237B51D2DCB4487A80@CY1PR03MB1374.namprd03.prod.outlook.com>
I think we're talking about two different scenarios.  I'm referring to same host + different port, which used to be allowed without TLS.  Allowing another host to serve the resource has (always?) required TLS, which means h2c just isn't a valid token for that scenario.

-----Original Message-----
From: Amos Jeffries [mailto:squid3@treenet.co.nz] 
Sent: Wednesday, February 10, 2016 8:22 PM
To: ietf-http-wg@w3.org
Subject: Re: draft-ietf-httpbis-alt-svc-12.txt

On 11/02/2016 10:31 a.m., Mike Bishop wrote:
> I agree.  For example, if the proposal of using a .well-known URI to 
> delegate to an Alt-Svc gets traction and becomes an RFC, it could just 
> update Alt-Svc to define that as having assurance as well.
> Note that h2c on the same port doesn't need Alt-Svc, since the
> Upgrade: header from the server is already defined.  So what we're 
> really talking about is h2c *on a different port*.  Honestly, I think 
> if we put it on a different port and publish an Alt-Svc pointing to 
> it, we might as well go direct (i.e. don't Upgrade from HTTP/1.1 on 
> the new connection), which would need a new token anyway.

Isn't that the point of Alt-Svc though? to have *both* servers able to deliver the resource, and to inform client of the non-usual alternative rather than the normal server always 302 redirecting.


Received on Thursday, 11 February 2016 05:12:24 UTC

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