etag caching not working as expected about moa

[evgenyneu]

Hi @ThomasGrunewald, this is very interesting, thanks for reporting. This project has a demo iOS app that shows the images in the scroll view. On the server I have set the expiration to 30 sec to match yours.

Response for one of the images: http://evgenii.com/files/2015/06/moa_demo/ChirogaleusMiliiSmit.jpg

ETag    "5771cabd-4731"
Cache-Control   max-age=30

Once all the images are downloaded by the app, it sends all the subsequent requests with the "If-" headers:

I could not reproduce your problem, for me it always sends "If-" headers after the first download for default settings. But then I reduced the sizes of both the memory and disc cache to 512 KB.

// Change memory cache size. Default is 20 MB.
Moa.settings.cache.memoryCapacityBytes = 512 * 1024

// Change disk cache size. Default is 100 MB.
Moa.settings.cache.diskCapacityBytes = 512 * 1024

Now it started sending the requests without the "If-"headers. I guess this is happening because the cache size is not enough to keep all the images in it.

If your images are large and/or there are a lot of them that default cache may not be large enough to store all the images. This is just a hypothesis. What do you think?

I was using Xcode 8, iOS 10 simulator and Charles proxy. I will keep my server running with 30 sec cache expiration for now so we can debug the problem.

[ThomasGrunewald]

Thanks for your quick reply @evgenyneu . I forgot to tell you about my testing environment. I am using Xcode 7.3.1/ iOS 9 Simulator / swift 2.2 and Charles proxy.
If I am putting my image url´s into your demo app everything work as expected. Seems like different caching (eatg) behavior between the iOS versions. ?

[evgenyneu]

That may be the case. I just tested the Swift 2.2 version of Moa in iOS 9 Simulator and Xcode 7. I could not reproduce your issue. It always sent subsequent requests with "If-" headers for me.

Here is how to jump back to the Swift 2.2 version:

git checkout tags/3.0.0

Maybe there are differences between our server responses as well. If you are willing to share your image URLs I would test them in the Swift 2.2 version of the demo and see if I can catch the problem.