A bad connection can be EXTREMELY slow, and a response time of few seconds can disrupt some applications also if all the requests got a 200 OK. You should check for the requests duration and alert if it's over one second.
I think you should also check the content of the file, can a bad connection drop some packets? As a side effect, knowing the length of the file you can calculate the bandwidth: maybe you have a good ping time but an ugly bandwidth, so the app broke because it's too slow to finish downloading some responses.
Also: timestamp instead of random, I think it's less CPU intensive 😊
Thanks a lot.
Can you expatiate more on this point
--> ...a response time of few seconds can disrupt some applications ...
Also, yea. Timestamp is a better choice 👍
In case of bad design of asynchronous calls with some degree of parallelization or sequentiality. A quick example because I'm writing on mobile: call A, then after one second call B, and the application assume that A will respond before B. On a bad connection A and B could return in the same instant, or even B before A. A poor coding choice could create an invalid state in the application. I'm speaking theoretically, but I've seen similar problems some months ago.
I think you should also check the content of the file, can a bad connection drop some packets?
In TCP it cannot. You either receive the packets correctly and in order from the OS, or the connection is terminated.
And I agree on using a timestamp, because 4 4 4 4 4 4 can be the result of multiple random() calls. There is a possibility of multiple users connecting via a proxy to get the same request. But I doubt proxies cache HEAD requests.
A bad connection can be EXTREMELY slow, and a response time of few seconds can disrupt some applications also if all the requests got a 200 OK. You should check for the requests duration and alert if it's over one second.
I think you should also check the content of the file, can a bad connection drop some packets? As a side effect, knowing the length of the file you can calculate the bandwidth: maybe you have a good ping time but an ugly bandwidth, so the app broke because it's too slow to finish downloading some responses.
Also: timestamp instead of random, I think it's less CPU intensive 😊
Thanks a lot.
Can you expatiate more on this point
--> ...a response time of few seconds can disrupt some applications ...
Also, yea. Timestamp is a better choice 👍
In case of bad design of asynchronous calls with some degree of parallelization or sequentiality. A quick example because I'm writing on mobile: call A, then after one second call B, and the application assume that A will respond before B. On a bad connection A and B could return in the same instant, or even B before A. A poor coding choice could create an invalid state in the application. I'm speaking theoretically, but I've seen similar problems some months ago.
In TCP it cannot. You either receive the packets correctly and in order from the OS, or the connection is terminated.
And I agree on using a timestamp, because 4 4 4 4 4 4 can be the result of multiple random() calls. There is a possibility of multiple users connecting via a proxy to get the same request. But I doubt proxies cache HEAD requests.
Oh, yeah, TCP, I didn't thought about it 😖
I didn't thought about proxy's caches either: maybe it would be better use some no-cache header.