Alt-Svc related Chromium bug report (proxy related)

I think I mentioned this to Mark offhand before, but I'm emailing the wider
list to inform more people in case it deserves a design consideration in
Alt-Svc or some informative text. We encountered some issues with
Alternate-Protocol that were nasty.

https://code.google.com/p/chromium/issues/detail?id=288992

There are a few issues here:
* The origin server is advertising Alt-Svc where the port matches the port
it's delivering the response on. This is because it was added via the nginx
add_header directive without discriminating on the specific service (http
vs https). This is arguably benign since the origin server supports SPDY
(HTTP/2) anyway, so whatevs.
* But the proxy server (a CDN) doesn't support SPDY (HTTP/2) yet. But it
doesn't understand Alt-Svc, so it passes it onward. But a subsequent
attempt to use the alternate service fails since it advertises the
requirement for SPDY (HTTP/2), which the CDN doesn't support. This
currently translates to a user-visible error, with a fallback in the
browser to ignoring the Alt-Svc directive on subsequent loads. Arguably, we
should transparently do the fallback and only show an error if that
fallback fails too. Of course, requiring a fallback like this is a
downgrade attack if you want the extra security of a more secure protocol
on that alternate service, but that's already the case in many parts of the
Alt-Svc proposal, so no new "harm" there.
* But the Chromium code for ignoring the Alt-Svc directive only added an
in-memory decision to ignore it. So if you restart the browser, we read the
persistent (Alternate-Protocol has no cache directive like Alt-Svc does),
and hit the same error condition again. That's simply a bug that we need to
fix.

Anyway, for the folks pushing on Alt-Svc, it's something to keep in mind.
Cheers.