Issue 694926  has been merged into this issue.

According to the code source and the net logs, this works as intended. 408 means that the client request hasn't reached the server. In that case, the client retries the request.

From the spec:
10.4.9 408 Request Timeout
The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time.

It looks that Chrome retries the request automatically. I think it is a reasonable way of handling this error code unless the server malfunctions and returns 408 for a wrong reason what results in an indefinite request/response loop.

https://cs.chromium.org/chromium/src/net/http/http_network_transaction.cc?type=cs&q=%22response_.headers.get()+%26%26+response_.headers-%3Eresponse_code()+%3D%3D+408%22&l=1252

There is no delay in the retry logic. This results in approx 400 requests per second with the local server. I think we should:
1) set a limit on the number of retries
and/or
2) fail right away if the server returns 408 unreasonably fast, e.g. within 1 sec.

Hrm...We're only retrying on 408 if we got a stale socket.  We generally rely on the stale-socket-only behavior to clean out the pools.  That should basically limit us to 2n connections for n requests (Ignoring any pre-existing idle connections, and preconnections).

Unless we have evidence the same can happen in H1, going to go ahead and remove the HTTP label - may be something different in HTTP2 session pooling that affects this behavior, but I don't see a way to get more than that number of connections with HTTP/1.x

Sorry, for HTTP/1.x, that should be just n new connections for n requests (Request gets stale socket from some other request, gets a 408, creates a new fresh socket - so that's just one new connection per request).  And we also have to go through any pre-existing sockets, of course.

 Issue 700224  has been merged into this issue.

Adding the QUIC label because this problem also happens with QUIC.

To add some color, this bug happens for data saver users that are using an H2 or QUIC proxy where the origin server (which is likely misconfigured) deterministically returns 408. I tracked down one case where a user made 480,000 requests that all received 408 responses and used over 900MB of data for 408 responses alone (!!!). We're going to mitigate this server-side for data saver users, so it's not a severe bug from our perspective, but there may be non-data-saver users that are seeing similar pathological cases when using H2.

I agree with #c5 that there should be a limit on retries, preferably a small constant.

I agree that the right approach here is the one outlined in comment #5.  I do not currently have free cycles for this, so I'm marking this as Available.

I think retrying on a 408 on QUIC / H2 doesn't make much sense - both protocols have their own way of timing out idle sockets, and we should rely on those, rather than 408s.  So maybe we should just restrict 408 retries to not happen with those protocols?

Comment#12: Yes, this is what happening on other browsers.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot