Clarify if `ProgressEvent.loaded` should indicate the size of compress, or uncompressed, data

[Zwyx]

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.

[annevk]

Firefox is correct. This is actually defined in detail through the interaction with Fetch. Content codings are removed before the creation of a response stream.

[Zwyx]

Thank you for replying. Would you be able to provide a link to where this is defined? I searched the Fetch spec for progress, leaded, compress, etc. but didn't find anything.

I'm also surprised the Fetch API has anything to do in XMLHttpRequest :thinking:, considering Fetch came around more than a decade later?