Baseflow / flutter_cache_manager

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

fileInfo.validTill returns incorrect date #249

Closed AnshulMahajan10 closed 3 years ago

AnshulMahajan10 commented 3 years ago

🐛 Bug Report

fileInfo.validTill is not returning the expected date. It returns current date only.

Expected behavior

fileInfo.validTill returns creation date + stale period.

Reproduction steps

static CacheManager instance = CacheManager( Config( "pdfCache", stalePeriod: const Duration(days: 17), maxNrOfCacheObjects: 20, ), );

File file = await instance.getSingleFile(url);

final fileInfo = await instance.getFileFromCache(url);
print(fileInfo.validTill);

Configuration

I'm using it to cache audio files with url

Version: 1.x

Platform:

AnshulMahajan10 commented 3 years ago

version flutter_cache_manager: ^2.0.0

renefloor commented 3 years ago

Expected behavior fileInfo.validTill returns creation date + stale period.

That is not the expected behavior. The stale period determines when an image is being deleted, not when an image is invalid. For example, when you have a stale period of 5 days. If you download and use the image once and never again it will be deleted from the cache after 5 days. However, when you show the image every day (for example on startup), the image will never reach the stale period of 5 days, but that doesn't mean the image is still valid.

The validity of the image is determined by the server using the cache-control header in the response. The header is used in 2 ways. 1) The header determines the period the file is valid using Cache-Control: max-age=<seconds>. If your validTill is always the same as the downloaded time the max-age is probably set to a small number. If the max-age is not set at all a default of 7 days is used. See here: https://github.com/Baseflow/flutter_cache_manager/blob/develop/flutter_cache_manager/lib/src/web/file_service.dart#L87

2) The eTag send in the response headers. When the image is not valid anymore because of the max-age the library sends a request to fetch the image again. But now it also sends the eTag with it. When the server recognizes with the eTag that the file is not changed it will not return the file, but a 304 Not Modified. This limits the data usages of the cache.

See this page for more information: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag

AnshulMahajan10 commented 3 years ago

thanks for your help