Re: Indicating Chosen Service #443

When we've started mocking up what we might implement here, it seems to be
impossible to prevent fairly common pathological situations without at
least a flag, at least when there is any overlap between the servers
handling initial and altsvc requests (which seems likely in some cases).
The hacks around this (different IPs, setting cookies and hoping they match
up, etc) get ugly fast.

I'd agree on what you suggest around the "do it right".  (ie, a frame that
directly mirrors the ALTSVC that was used.)

There are certainly risks around client fingerprinting if abused, although
particularly concerned clients could ignore the ALTSVC sent by the server.




On Fri, Apr 25, 2014 at 12:43 AM, Martin Thomson
<martin.thomson@gmail.com>wrote:

> On 24 April 2014 18:23, Mark Nottingham <mnot@mnot.net> wrote:
> > What do people think about the tradeoffs above, as well as doing this in
> general?
>
> I'm still not 100% convinced.  I guess that it depends on how complex
> you imagine the redirection chain will ultimately be.  For cases where
> alt-svc is moving clients from a "first-hit" server to the "right"
> server, then it's probably not that useful.  For load balancing
> scenarios, it's fairly straightforward for clients to detect
> flip-flopping and other pathological scenarios (similar in many
> respects to redirect loop detection; the difference there being that
> Referer and occasionally URL rewrites offer the server some hope of
> finding problems).
>
> If we do this, let's do it right.  A frame type that directly mirrors
> ALTSVC (yeah, SVC might work) - maybe omitting only the expiration
> time - is probably best.  That way a client can say to a server, I'm
> asking about this origin, because I received the following ALTSVC
> information.  You know, a client could just use ALTSVC.  Apart from
> one thing....
>
> We might want to examine this general mechanism for privacy purposes.
> We don't need yet another channel for client fingerprinting.
>