The “Concurrent Request” part concerns me. Just because the server thinks the original request is still going on doesn’t mean the client does. Example: Client

The “Concurrent Request” part concerns me. Just because the server thinks the original request is still going on doesn’t mean the client does. Example: Client issues a request with a 10 second timeout. Network conditions are such that the request doesn’t get fully sent until 9.9 seconds have passed (at which point network conditions have cleared and are fast). Client gets a timeout, immediate retries. From the client’s perspective, there’s no concurrent request. What the server sees is a request followed 0.1 seconds by an identical request. It naturally says “I’m not done with the first, the second is a concurrent request” and sends the required error. Net result is the server has applied the request but the client is left with an error. The client must now send a third identical request just to find out the actual results. Ultimately, the problem boils down to the fact that the client and server do not necessarily have the same idea of what requests are currently in-flight. And yet this draft declares that the server MUST return an error if it thinks the request is still being processed.