Re: Indicating Chosen Service #443

As an option (d), which might be rejected out of hand:

d) a HEADER sent early in the connection on streamid 0 with something like:
     { ":svc", "h2;alt.example.com:443" }

I do wonder if we'll keep running into other cases where we want
connection-level key/value extensibility without needing to add new frame
types each time?

     Erik

Sent from my mobile device
On Apr 24, 2014 9:22 PM, "Mark Nottingham" <mnot@mnot.net> wrote:

> 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/
>
>
>
>