3 ms·
1. You know the size of the compressed data from the Content-Length header. 2. You can iterate through the uncompressed response bytes with a ReadableStream.
by meindnoch 2y ago
1. You know the size of the compressed data from the Content-Length header.
2. You can iterate through the uncompressed response bytes with a ReadableStream.
Please explain how would you produce a progress percentage from these?
- lmz 2y agoIf you had control of both ends you could embed a header in the uncompressed data with the number of uncompressed bytes.
- mananaysiempre 2y agoOr put that length in the response headers.
- meindnoch 2y agoYou won't be able to do this if you're downloading from a CDN. Which is exactly where you would host large files, for which progress reporting really matters.
- floating-io 2y agoWhy not? Every CDN I've ever worked with preserves custom headers.
- meindnoch 2y agoRight. For example S3 supports custom headers, as long as that header happens to start with "x-amz-meta-..." - and now your progress reporting is tied to your CDN choice! Not sure about you, but to me "XmlHttpRequest" in my request handling code feels less dirty than "x-amz-meta-". But to each their own I guess.
- floating-io 2y agoS3 is not a CDN. Check CloudFlare, Akamai, ...
- meindnoch 2y agoGood idea. We could give it a new MIME type too. E.g. application/octet-stream-with-length-prefix-due-to-idiotic-fetch-api Or we can keep using XmlHttpRequest. Tough choice.
- badmintonbaseba 2y ago"processed uncompressed bytes"/"all uncompressed bytes" is a distorted progress indication anyway.
- jstanley 2y agoRecompress the ReadableStream to work out roughly how long the compressed version is, and use the ratio of the length of your recompressed stream to the Content-Length to work out an approximate progress percentage.
- meindnoch 2y agoLol! Upvoted for creative thinking.
- leptons 2y agoMany large files that get downloaded are already compressed, so using compression during http response is pointless and just adds overhead. If you need progress on a text file, then don't compress it while downloading. Text files that are small won't really need progress or compression. If you're sending a large amount of data that can be compressed, then zip it before sending it, download-with-progress (without http compression), and then unzip the file in the browser and do what you need with the contents. I'm sure there are probably other ways to handle it too.
- meindnoch 2y ago>I'm sure there are probably other ways to handle it too. Yes, there is. The simplest solution is called XmlHttpRequest, which has a "progress" event that correctly reports the response body bytes. You can even make a wrapper for XmlHttpRequest and call it "myFetch()" if you insist.
- leptons 2y agoThat doesn't change the fact that it is possible to use fetch with progress.
- meindnoch 2y agoSure, it is possible to use fetch() with progress, as long as Content-Encoding is not used. Which is precisely what I've said in my first comment.
- leptons 2y agoAnd I've explained why, in most cases, Content-Encoding doesn't need to be used for async download with progress monitoring.