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

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.

Amos

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