FileLoader: Add response headers to onProgress callback

[JordyvanDortmont]

Description

Since #22510 the response headers can't be accessed anymore in the progress callback. A custom response header can be used to send the uncompressed content length of large compressed files (gzip, brotli) to report loading progress to the user. The total content length currently reported by the ProgressEvent, is the content length of the compressed file and the loaded bytes are currently reported for the uncompressed file loading progress of the ReadableStream. Even with the new Fetch API, this is still an unresolved issue: whatwg/fetch#1358.

Before the Fetch API was introduced, the onProgress callback received the XMLHttpRequest object as the event target, which gave access to the response headers.

This PR adds the response headers as an argument to the onProgress callback to provide access to the response headers again.

[gkjohnson]

I'm thinking instead of creating a ProgressEvent instance we just create a custom object with the information we want in the object. Something like:

const event = {
  lengthComputable,
  loaded,
  total,
  response,
};

There's no reason the passed object has to be a ProgressEvent.

[LeviPesin]

Can it be const event = new ProgressEvent( 'progress', { lengthComputable, loaded, total, response } );?

[gkjohnson]

No from the docs "response" is not a valid field for ProgressEvent.

[LeviPesin]

Ah, yes... Then the object approach is better.

[JordyvanDortmont]

That'd be great as well. Let me know if I should make the change, then I can change the docs accordingly.

[gkjohnson]

I'll have to defer to @mrdoob and @Mugen87 on whether or not the object approach is preferred.

[Mugen87]

Maybe we can start with a custom object and if someone complains we fallback to the initial approach of the PR?

[JordyvanDortmont]

I changed it to a custom object including the response and I also updated the docs.

[JordyvanDortmont]

This has been fixed by #24971.

[JordyvanDortmont]

Unfortunately my previous comment was a bit too soon. For compressed files the compressed file size is sent with the Content-Length header, which takes precedence over the X-File-Size header currently, which could be used to specify the uncompressed file size.

To solve our issue, either the X-File-Size header needs to take precedence, or we would still need this PR.