Re: Clarification on Alternative Service Connection Failures

On Fri, Sep 29, 2017 at 2:11 PM, Lucas Pardue <Lucas.Pardue@bbc.co.uk>
wrote:

> I'm inferring from the responses that Firefox and Chrome currently don't
> do much in this regard for handling all variations of errors. Although
> perhaps 421 is special because there is explicit text describing what to do.
>

I can't speak to the behavior of Firefox, but Chrome basically only stops
using an alternative where there are connection errors. HTTP response codes
do not factor into this decision at all. It wouldn't be terribly hard to
implement, of course. But when we implemented this logic we thought that
connection failures were the "right" kind of failures to look at.
Conveniently, since they happen when the connection is established, it
means that idempotency of requests does not come into play.


> Of course, it is not just browsers that are affected by this. Curl is
> looking to add Alt-Svc support [1], and in our case Sam's been working on
> an Alt-Svc component for software/intermediaries with no real user facing
> UI.
>
> I'm not sure how general the advice could be but I think it could be
> useful (a BCP?). RFC 7838 already calls out that "it is advantageous for
> clients to behave in a predictable way when alternative services are used
> by servers".
>
> I'd hazard a guess that QUIC's ongoing development and deployment will see
> more people coming to Alt-Svc. The easy thing to do is to just scrape
> response headers for the presence of "Alt-Svc: hq=..." and then start
> switching action, it's feasible this might not match the expectations of
> the server deployment. E.g. short cache lifetimes that are ignored the
> client.
>
> I'm also reminded of previous thoughts I've had about documentation of
> strategies for opening up a connection to the alternative in the
> background, and whether the client is restricted to only selecting a single
> alternative (i'm sure its in the RFC but can't find that particular line
> right now).
>

​Document this seems sensible. That being Chrome only connects in the
background when it has a connection open to the​ original server. If it
does not have an open connection then it'll only open a connection to the
alternative, unless that fails. This is because we expect alternatives to
mostly work and hence we don't want to waste resources creating two
connections when one would suffice.