RE: Clarification on Alternative Service Connection Failures

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.

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

Lucas

[1] https://github.com/curl/curl/wiki/QUIC

________________________________
From: Ryan Hamilton [rch@google.com]
Sent: 29 September 2017 20:50
To: Patrick McManus
Cc: Sam Hurst-RD; HTTP Working Group
Subject: Re: Clarification on Alternative Service Connection Failures

On Fri, Sep 29, 2017 at 12:48 PM, Ryan Hamilton <rch@google.com<mailto:rch@google.com>> wrote:
On Fri, Sep 29, 2017 at 6:27 AM, Patrick McManus <mcmanus@ducksong.com<mailto:mcmanus@ducksong.com>> wrote:
The text is referring to any failure - the client MAY want to try a different alternative in that case. Its just saying don't feel pinned down by an Alt-Svc announcement just because you started to use it - you can always use a different one (or the default) if you think it would work better. A 500 seems a reasonable input to that choice to me.

​Wow, really? Hm. While I understand your reasoning here, I don't love it. It seems like we might want to have more concrete advice to browsers about what kinds of failures should count as a failure. Otherwise we'll end up with different behavior in different browsers for no terribly good reason. For example, what about 4xx errors? Should all 4xx and all 5xx errors count? What behavior should servers be able to count on? Is it "safe" to advertise an alternative which is not current reachable (I think so). What about one which 404s for all requests, or one which 500s every request? Should this be considered "safe" for a server to advertise?

I'm not sure I have a terribly well thought out idea here, but this makes me a bit nervous.

​One more thought. Should non-idempotent requests be resent in the case where an alternative 500s?​