Re: Alternative Service Indication

On Fri, May 2, 2014 at 1:15 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> On 2 May 2014 12:59, William Chan (陈智昌) <willchan@chromium.org> wrote:
> > The difference here is that we're leaking more information
> (theoretically to the
> > same server, so it's not really an information leak).
>
> It is a problem only because clients can have altsvc information
> persisted for a very long time.  This produces a way of correlating
> requests from clients between connections.  (Even if we decide to drop
> this indicator, those tracking concerns are worth retaining; there's
> still the implicit leak.)
>

Good point. And yeah, this line of reasoning is why I'm hesitant to do
this, and would really like more intermediary vendors to come out and say
"we need this".


>
> > I would contrast this with HTTP redirect loops which never terminate and
> we
> > show an error for after too many redirects. But with ALTSVC, if you race
> the
> > different connections anyway, then everything will always work. It'll
> just
> > be suboptimal since you're setting up and tearing down connections all
> the
> > time.
>
> Yes, that's exactly the analogy I was using.  The only difference is
> perhaps that the damage can be hidden.  Everything continues to work,
> but you spend more time on new connections than might be ideal.
>

Well, I can tell you we're going to try to write less code if possible :)
But if we see clear evidence that this type of bug is widespread and there
are easy heuristics for working around server silliness, we'll code
something up. But I wouldn't expect to see any such behavior for awhile
until HTTP/2 is more widely deployed. We'd just work with our relevant
contacts operating major servers to inform them that they're being silly
and they should fix it. HTTP redirect loops happen even when servers have
referer links, so it's not like providing this information is magically
going to make ALTSVC loops go away (especially if the loop is a longer
chain than a single hop, since the server can't detect that purely from the
alternative service info). It might help servers eliminate some issues, but
we shouldn't overstate the utility of this information for the loops.