5 ms·
It's not just an easy JS fix though. It complicates quite a lot on the server side. Your timed out request could have reached the server already, so the state
by comboy 10y ago
It's not just an easy JS fix though. It complicates quite a lot on the server side. Your timed out request could have reached the server already, so the state would different now. From the server perspective it's not clear whether it was a retry or another request (and some actions are meant to be repeatable).
Now that I think about it, generating some request UUID and passing it to the server could allow it to quickly skip duplicates (it would also need to cache responses for resending them).
I'm also curious how often this problem occurs statistically (not just in your case, but for an average user of popular sites)
- akiselev 10y agoWouldn't it be easier to add a retry=true to the request, at least if your implementing exponential back off in an existing codebase? Then you just hash the request (minus the retry field) in your cache layer and send the saved response again. You'll need a little extra code to update timestamps on the client side but the server side can be implemented as middleware in most frameworks. Expire the cache after a reasonable total timeout and make the client do a new read if they try to retry after cache has cleared it.
- deleted 10y ago[deleted]
- comboy 10y agoI think you need client side UUID instead of just retry=true for requests that can be repeated with the same params. E.g. /inrement?retry=true, server gets 3 of them - how many times should it increment? Is it just that user still haven't received the first response, or should we increment 3 times because it was send/fail/retry/ok 3 times on the client side? But with this UUID it still can be easily implemented as a middleware.
- derefr 10y agoMind you, we're talking about "sanity checks" here, not actions: presumably these are XHR GETs. In HTTP-semantic terms, you're always allowed to retry GETs, and they're always supposed to be idempotent (or not change state at all, but that's a lost battle.) There's no reason that the browser shouldn't default to automatically retrying (with back-off) GET XHRs, save for how many sites are built without a proper understanding of HTTP semantics.