Re: Clarification on Alternative Service Connection Failures

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.

On Fri, Sep 29, 2017 at 7:10 AM, Samuel Hurst <samuelh@rd.bbc.co.uk> wrote:

> Hi,
>
>
> I've got another question about HTTP Alternative Services [RFC7838]. In
> section 2.4, it says the following:
>
> > if the connection to the alternative service fails or is unresponsive,
> > the client MAY fall back to using the origin or another alternative
> > service
>
> What actually counts as a failure in the connection? Is it only for
> transport/network layer connection failures, or could an application
> layer failure also count?
>
> For example, I make a request to a http origin and it responds with a
> valid Alt-Svc header indicating that there is a https alternative.
> Connecting to the https origin succeeds and I can make my request.
> However, that https alternative has been misconfigured or is otherwise
> having issues and it returns a 500 Internal Server Error response for my
> request. Would that be considered a failure of the connection?
>
> In addition, if the request to another alternative or back to the origin
> succeeds, would it then be wise to drop the failing alternative from my
> Alt-Svc cache?
>
> The way I've read it, I think that a 500 series response would be
> considered a failure, and I would mark it as a bad alternative in my
> cache and then make another request to the next highest priority
> alternative (or back to the insecure origin if the application is okay
> with this).
>
>
> Best Regards,
> Sam
>
>