Currently in our implementation of H5P, we load the entire H5P file into the frontend and then extract all its constituent files into Blob objects and create URLs for them.

This has the distinct advantage of being very robust and being very predictable. It has the slight downside of causing incredibly long loading times for H5P files that contain large bundled media files such as video or audio.

Once #9157 has been implemented, it would be useful to augment the zip file wrapper in the following ways:

Instead of reading the entire file at once, first read the file metadata and listing in the zip file via a range request. To accomplish this we can use try to either directly use zipinfo.js or vendor it and modify it for our needs.

For reference, this is a Python implementation of a similar mechanism https://github.com/saulpw/unzip-http.

Once we have the listing of all the files, in a minimal number of requests, we load and unzip all files below a certain size cut off (say 500KB) at which we decide to defer loading of a file.

For any files not loaded through the above mechanism, we do the following:

• First we enhance the zipcontent endpoint to support range requests, this will allow video and audio files to be easily played - due to a lack of support for a seek method in Python 3.6 on extracted files, we will have to brook some inefficiency on Python 3.6 backends.
• Secondly, we enhance the zipfile wrapper to allow passing a function to generate the URL for the large file. If this is present, then it will defer to this URL generating function for large files, if not, it will behave as it currently does. We then inject this function where it is needed to provide appropriate references to the zipcontent endpoint.
• Thirdly, we will update the zipcontent endpoint to serve files from within any compressed file format (again).