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