Description
What is the issue with the XMLHttpRequest Standard?
When a ProgressEvent fires, ProgressEvent.loaded contains the size of the data already transmitted.
If the data is compressed and its total size is unknown, then, depending on the browser, ProgressEvent.loaded can contain either the size of the compressed data, or the size of the decompressed data.
It would be great if the spec could clarify which of these two values should be the one provided by ProgressEvent.loaded.
Additional context
With a response containing compressed data and unknown total size (the Content-Length header is not set), ProgressEvent.lengthComputable is false and ProgressEvent.total is not usable, preventing us from displaying a progress indicator.
In this case, a common technique is to set a custom response header X-Uncompressed-Content-Length containing the size of the uncompressed data being transmitted.
We can then, on the client side, use the value of this header as a substitue of ProgressEvent.total, and display a progress indicator with the value of ProgressEvent.loaded divided by the value of this header.
However, depending on the browser, ProgressEvent.loaded can be either the size of the compressed data already transmitted (the case in Firefox), or, the size of the decompressed data already transmitted (the case in Chrome).
For example:
- In Chrome, downloading a content of 1.3MB (1,345,276 bytes), while logging the value of
loaded, shows a total of 1345276 at the end. - In Firefox, downloading the same content of 1,345,276 bytes, while logging the value of
loaded, shows a total of 1017454 at the end.