Re: Alternative Service Indication

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

> On 2 May 2014 12:34, William Chan (陈智昌) <willchan@chromium.org> wrote:
> > "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."
> >
> > I am not sure how to do this load attribution correctly if
> > us-east-2.example.com might also be pointing to it, as pointed out as a
> > possibility in Erik's email.
>
> I'll confess that I didn't find that one especially compelling.  It's
> nice to have, but I imagine that many of these cases are adequately
> addressed by examining Host header fields.
>

That's fine then. Just wanted to point it out that I think there's
information loss in the proposed approach here, but if it's a minor use
case and the information is sufficient, then great.


>
> The potential for looping seems like a more valid reason to *require*
> the use of an indicator.
>

Can you explain why? It's a server bug. If the server is screwing itself
over, it should debug and fix it. It's not a user visible error, as in
everything will still work. Now, the question is should we make this easier
for the server to debug. This is kinda similar to the BLOCKED frame
discussion. Things work, but work suboptimally in certain situations. The
difference here is that we're leaking more information (theoretically to
the same server, so it's not really an information leak).


>
> That is, if Server A and Server B are both alternatives, then it might
> be perfectly valid to have them both offload onto each other.  But
> that's usually something that you want to have happen on a longer time
> scale.  As Erik notes, rapid bouncing back and forth could be a
> problem.  I had assumed that clients would have to protect themselves
> against bad servers doing this anyway [1].  I think that I'd prefer
> that.
>

What protection do you mean? 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.


>
> The potential for tracking using this mechanism means that we need a
> clear, strong reason for mandating a mechanism.  (The reason I created
> the PR was to try to drive discussion to conclusion :)
>

You succeeded in catching my attention :)


>
> [1] I need to create security considerations regarding this...
>