When doing cross-origin requests in Safari, the ResourceTiming transferSize field is force set to 0. There is more background into this behaviour in this issue: https://github.com/w3c/resource-timing/issues/222
The consequence is that download bandwidth calculations were using the value of this field as the numerator of the size/time equation, if it was present, leading to a miscalculation of 0 bps in these circumstances. This PR fixes that by interpreting a transfer size of 0 as a missing field, and falling back to an estimation of the transfer size based on the bytes that were requested. This addresses https://github.com/cloudflare/speedtest/issues/15.
To note that this security behaviour only happens if the request is cross-origin, which explains why the issue isn't visible on the site https://speed.cloudflare.com since both the client and the server are on the same domain.
It also only affects Safari based browsers.
In addition, dev dependencies are bumped in this PR.
When doing cross-origin requests in Safari, the ResourceTiming
transferSize
field is force set to0
. There is more background into this behaviour in this issue: https://github.com/w3c/resource-timing/issues/222The consequence is that download bandwidth calculations were using the value of this field as the numerator of the
size/time
equation, if it was present, leading to a miscalculation of0 bps
in these circumstances. This PR fixes that by interpreting a transfer size of0
as a missing field, and falling back to an estimation of the transfer size based on the bytes that were requested. This addresses https://github.com/cloudflare/speedtest/issues/15.To note that this security behaviour only happens if the request is cross-origin, which explains why the issue isn't visible on the site https://speed.cloudflare.com since both the client and the server are on the same domain.
It also only affects Safari based browsers.
In addition, dev dependencies are bumped in this PR.