Open Zwyx opened 5 months ago
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.
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?
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
isfalse
andProgressEvent.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 ofProgressEvent.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:
loaded
, shows a total of 1345276 at the end.loaded
, shows a total of 1017454 at the end.