11 ms·
If you had control of both ends you could embed a header in the uncompressed data with the number of uncompressed bytes.
by lmz 2y ago
If 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.