search

Baseflow / flutter_cache_manager

Generic cache manager for flutter
https://baseflow.com
MIT License
749 stars 436 forks source link

Support for partial content #247

Open hongfeiyang opened 3 years ago

hongfeiyang commented 3 years ago

🏗 Enhancement Proposal

Pitch

Hi, could you please add support for HttpStatus Code 206 partial content please. My use cases involves binary data and each file uses the Http Range header and with response code 206 (partial content) to separate each chunk. Chunks may change but the all chunks from the same file have the same url. Currently there is no support for this, so it would be awesome if you guys can consider this as additional to the exisiting functionality.

Platforms affected (mark all that apply)

renefloor commented 3 years ago

I don't have any experience with it, but I can look into it. How would you normally indicate which parts you need?

hongfeiyang commented 3 years ago

@renefloor The same as what's stated in the docs of MDN HTTP Range Request https://developer.mozilla.org/en-US/docs/Web/HTTP/Range_requests

The request will have header Range , for example, Range: bytes=0-1023, and the response headers would include something like Content-Range: bytes 0-1023/146515 Content-Length: 1024 with HTTP status code 206, while the request url remains the same for each Range. I saw there is a headers parameter in functions like getSingleFile() and this would be a good starting point to add this 'Range` header

hongfeiyang commented 3 years ago

Just treat each chunk as small individual binary files and if someone makes a request to retrieve the same chunk of the same file it can return that chunk of binary data either from cache or download from web

renefloor commented 3 years ago

Currently the file is stored based on the url or the key. If you'd request the same url with a different range the data would be overriden. That would mean a user of the library needs to separate that using keys, for example: key: image0-1023.

I think it makes more sense to directly download all ranges and combine them in 1 file, but for that we need to know that we have to download it in parts.

hongfeiyang commented 3 years ago

Currently the file is stored based on the url or the key. If you'd request the same url with a different range the data would be overriden. That would mean a user of the library needs to separate that using keys, for example: key: image0-1023.

I think it makes more sense to directly download all ranges and combine them in 1 file, but for that we need to know that we have to download it in parts.

Yes I would be a solution too, but I see caching each chunk has it own advantage, imagine if you have a large video file like a movie and you skipped to the end to see the ending. And you cached the very last 1 minute. Then later you want to revisit that part because it's so good, so you open the same URL and skipped to the end, I think it would be wonderful if you could still watch that cached part. Or if you are downloading a huge file and in the middle of the download you paused and later reopen that download and don't want to download the previous part again and the file only makes sense when all parts are completed