Re: Indicating Chosen Service #443

I think it'd be helpful to talk about concrete proposals here.

AFAICT there are a number of ways to do this, based on discussion to date:

a) A new HTTP request header, to be sent upon the first request (at least); e.g., 
   Service: h2;alt.example.com:443

b) A new frame type (maybe SVC?) whose payload is a serialisation of the alternative service tuple

c) A flag to send in SETTINGS that indicates an alternative service is in use

Each of these has its downsides; (a) feels like a layer violation, but is easy to do; (b) might be considered "heavy", but is probably the "correct" way to do this, and (c) is very easy to do, but doesn't provide all of the information.

Are there any others?

What do people think about the tradeoffs above, as well as doing this in general?

Cheers,



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

> On Mon, Mar 31, 2014 at 12:37 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> >From @mnot in #443:
> 
> It's likely necessary for the server to know which protocol the user
> agent has chosen, and perhaps even the hostname (for load balancing).
> At the very least, there should be a flag in SETTINGS that indicates
> that an alternate service has been used.
> 
> >From me:
> 
> How is it that the combination of the protocol that is actually in
> use, and maybe Via, is not sufficient?
> 
> As in, you get a connection from a client, using HTTP/2.  That's
> usually a good sign that they are connecting via HTTP/2.
> 
> Presumably you know the names you can be reached by (it isn't always
> true that you know what DNS records point to you, conceded, but let's
> pretend that you aren't operating completely blind).  But that doesn't
> matter, because what's actually important is what domains you are
> claiming to be authoritative for, which you have to know.
>   
> So, why?
> 
> 
> This is particularly important when using the ALTSVC frame to send traffic to a different hostname but the same protocol, especially if any individual server might have many hostnames by which it could be reached, and if the hostname sets are overlapping.  The ALTSVC hostname is routing information, and if the recipient of the connection doesn't have this information it can be problematic to avoid loops, provide stickiness, troubleshoot, and know where load is coming from for load-balancing purposes.
> 
> For example, if you return "ALTSVC: port=443, proto=h2t, host=us-east-1.example.com, max-age=360" for www.example.com then it's highly valuable for the server at us-east-1.example.com to know that it was reached that way (as it might also have us-east-2.example.com and us-east-1.example.org pointing to it).  This would allow it to: 1) know that it shouldn't return another ALTSVC frame immediately (loop prevention); 2) give some sense for other preferable ALTSVC host values should be for nearby session affinity if returning another ALTSVC before a GOAWAY/DRAIN; 3) allow it to log how clients got there for diagnostics purposes; and 4) allow it to report load properly associated with us-east-1.example.com, especially if other DNS names could have been used to reach it.  
> 
> Not all scenarios will require all of these.  However, not passing through routing information to servers that can be reached multiple ways has turned out to be unfortunate down the road for multi-tenant situations (lack of manditory Host header in the first HTTP versions, lack of SNI in TLS, etc).
> 
>            Erik
> 

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

Received on Friday, 25 April 2014 01:22:27 UTC