You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a follow-up to issue #487. I noticed that some recent SDK versions include attempts to address this problem, but I’d like to provide additional context that might help fully resolve it.
Since version 12.9.0, we’ve been unable to read network responses in the network logs. This is what we’re seeing in our dashboards:
After some investigation, we found that the issue is caused by the following check in the SDK, which aims to filter out file downloads:
However, using the Accept-Ranges header for this purpose is problematic. This header simply indicates that the server supports partial requests, not that the current response is a partial download. As explained in MDN, its presence alone doesn’t imply that a file is being downloaded.
A more reliable approach would be to check for HTTP status code 206, or look for the presence of the Content-Range header, which directly indicates that the response is a partial content delivery.
Hope this helps clarify the issue and move us closer to a permanent fix.
Best regards.
The text was updated successfully, but these errors were encountered:
@Pato94 Thank you for taking the time to dig deeper into this and reporting it. 🙏
The issue has already been addressed and a fix will be shipped with our upcoming version, v14.3.0.
I'll close this for now and please feel free to re-open it if needed.
Hello,
This is a follow-up to issue #487. I noticed that some recent SDK versions include attempts to address this problem, but I’d like to provide additional context that might help fully resolve it.
Since version 12.9.0, we’ve been unable to read network responses in the network logs. This is what we’re seeing in our dashboards:
After some investigation, we found that the issue is caused by the following check in the SDK, which aims to filter out file downloads:
However, using the Accept-Ranges header for this purpose is problematic. This header simply indicates that the server supports partial requests, not that the current response is a partial download. As explained in MDN, its presence alone doesn’t imply that a file is being downloaded.
A more reliable approach would be to check for HTTP status code 206, or look for the presence of the Content-Range header, which directly indicates that the response is a partial content delivery.
Hope this helps clarify the issue and move us closer to a permanent fix.
Best regards.
The text was updated successfully, but these errors were encountered: