Subject: Alternative Service Indication

From: Martin Thomson <[email-masked]>
Date: Thu, 1 May 2014 14:21:54 -0700

The discussion we've been having on this topic seems to have
converged, or at least cooled a little.

I've put together a pull request that combines the following changes:

1. Clients can send an ALTSVC frame to indicate the service that is in
use.  This is HTTP/2 only, obviously.  The main advantage of this is
that you can send a single frame.

2. Clients can send an Alt-Svc header field to indicate the service
that is in use everywhere else.  This has to be on every request
(i.e., no change).

3. Remove the Service header field in favour of the above.

4. Add some security considerations around the use of these indicators
for tracking clients.  I was a little concerned about this at first,
but now that I've done the thinking, the concern seems manageable.

See the text here:
https://github.com/http2/http2-spec/pull/474

--Martin

---

From: Erik Nygren <[email-masked]>
Date: Thu, 1 May 2014 21:27:39 -0400

This looks good to me.

   Erik

---

From: William Chan (陈智昌) <[email-masked]>
Date: Thu, 1 May 2014 18:40:31 -0700

I somehow missed the previous discussion thread on it. Sorry about that. I
have some comments now though :)

* I'd like to hear more people discussing it. The only participants on the
last thread that I saw were Martin, Mark, and Erik. Can others chime in?
* It's interesting to me that this appears to be mandatory for clients. I
need to think about this more deeply.
* I need to think more deeply about how necessary this is. My default as a
client is not to provide something unless there's a clear reason to do so.
Are there any examples of things *breaking* without this? AFAICT from
previous discussions, there are some server suboptimalities, and this would
be nice to provide. I'm trying to evaluate how "nice" this is vs mandatory.
I consider the Host header to be pretty important to the web as it operates
today, but am unclear on how this compares.
* Does sending an ALTSVC frame play nice with connection sharing? I haven't
thought about it too much.

Cheers.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 1 May 2014 22:06:07 -0700

> last thread that I saw were Martin, Mark, and Erik. Can others chime in?

Yes, please.

> need to think about this more deeply.

Erik and Mark seem convinced.  Me, less so, but I have to give these
guys some credit for having to deal with issues that I don't think
I've ever seen.

> thought about it too much.

Actually, I think that this is a net win for servers in that regard.
But that alone probably doesn't justify it.  Servers get notified when
clients decide to use alternative services.  I think that the previous
question is the determining one for me.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Fri, 2 May 2014 12:34:10 -0700

> guys some credit for having to deal with issues that I don't think

I definitely give them credit too, but I'm hesitant to proceed when no
other intermediary vendor has been asking for this. So yes, other vendors,
please chime in :)

> question is the determining one for me.

Well, in Erik's justification (4):

"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.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 2 May 2014 12:50:38 -0700

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

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

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.

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 :)

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

---

From: William Chan (陈智昌) <[email-masked]>
Date: Fri, 2 May 2014 12:59:37 -0700

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

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).

> against bad servers doing this anyway [1].  I think that I'd prefer

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 PR was to try to drive discussion to conclusion :)

You succeeded in catching my attention :)

---

From: Martin Thomson <[email-masked]>
Date: Fri, 2 May 2014 13:15:12 -0700

On 2 May 2014 12:59, William Chan (陈智昌) <[email-masked]> 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.)

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

---

From: William Chan (陈智昌) <[email-masked]>
Date: Fri, 2 May 2014 13:22:05 -0700

> 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".

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