W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2021

Retrying requests sent to Alternative Services

From: Ryan Hamilton <rch@google.com>
Date: Wed, 15 Sep 2021 11:53:58 -0700
Message-ID: <CAJ_4DfRzydZATfg1NBAmv3NuVao73KmSBVLU2Fig0NOr7=vMrQ@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
Howdy Folks,

I'd like to get thoughts from folks about what circumstances a client
should resend a request to the origin server directly that was originally
sent to an alternate service. For example, Section 2.4 of RFC 7838
<https://datatracker.ietf.org/doc/html/rfc7838#section-2.4> has the
following text.

Furthermore, if the connection to the alternative service fails or is
unresponsive, the client MAY fall back to using the origin or another
alternative service.


But I'm curious about a few other cases that clients might consider. What
if the alternative server is responsive, but the connection is aborted
because of a protocol error? (For example, the connection is closed because
of a QUIC level protocol error like an ACK of a packet that was never
sent). What about the case where a 500 error code (Internal Server Error)
is received?

For example, Chrome has logic
<https://source.chromium.org/chromium/chromium/src/+/main:net/http/http_network_transaction.cc;drc=11c88cd72d68adfbdb88e55a6841724674eac5d3;l=1656>
which
retries any request that was sent to an alternative and encountered a QUIC
(or HTTP/3) error including the connection timing out. If the resulting
(TCP) request succeeds, then the alternative service is disabled for some
period of time. Chrome does not, however, retry requests on 500 errors.

I'd be very interested to hear what clients are doing in practice both in
terms of the situations that result in a retry and any effect that retry
might have on subsequent use (or not) of the alternative service.

Cheers,

Ryan
Received on Wednesday, 15 September 2021 18:54:26 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 15 September 2021 18:54:29 UTC