Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Weird behavior with URLCache #31

Closed
felginep opened this issue Mar 15, 2019 · 3 comments · Fixed by #62
Closed

Weird behavior with URLCache #31

felginep opened this issue Mar 15, 2019 · 3 comments · Fixed by #62
Labels
Milestone

Comments

@felginep
Copy link

felginep commented Mar 15, 2019

There is a weird bug related to custom URLSession and URLCache.

Project setup

Here is my AppDelegate that enables DBDebugToolkit.

class AppDelegate: UIResponder, UIApplicationDelegate {

    var window: UIWindow?

    func application(_ application: UIApplication,
                     didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {

        DBDebugToolkit.setup()

        let window = UIWindow(frame: UIScreen.main.bounds)
        self.window = window
        window.backgroundColor = UIColor.white
        window.rootViewController = ViewController()

        window.makeKeyAndVisible()
        return true
    }
}

In my ViewController, I have a button that loads an url with Cache-Control header set, meaning the system should cache the response.

class ViewController: UIViewController {

    private lazy var button: UIButton = {
        let button = UIButton(type: .system)
        button.setTitle("Load", for: .normal)
        button.addTarget(self, action: #selector(load), for: .touchUpInside)
        return button
    }()

    // Custom URLSession with custom cache and custom diskPath
    private lazy var session: URLSession = {
        let memoryCapacity = 500 * 1024 * 1024 // 500 MB
        let diskCapacity = 500 * 1024 * 1024 // 500 MB

        let cache = URLCache(
            memoryCapacity: memoryCapacity,
            diskCapacity: diskCapacity,
            diskPath: "com.xxxxx.yyyyy"
        )

        let configuration = URLSessionConfiguration.default
        configuration.urlCache = cache

        return URLSession(
            configuration: configuration,
            delegate: self,
            delegateQueue: nil
        )
    }()

    override func viewDidLoad() {
        super.viewDidLoad()
        view.addSubview(button)
        button.frame = view.bounds
    }

    // MARK: - Private

    @objc private func load() {
        // A ~130 KB image, small enough to be cached by the default URLSession session
        let url = URL(string: "https://images.unsplash.com/photo-1518791841217-8f162f1e1131?ixlib=rb-1.2.1&auto=format&fit=crop&w=1000&q=80")!
        session.dataTask(with: url).resume()
    }
}

extension ViewController: URLSessionDataDelegate {

    // MARK: - URLSessionDataDelegate

    func urlSession(_ session: URLSession,
                    dataTask: URLSessionDataTask,
                    willCacheResponse proposedResponse: CachedURLResponse,
                    completionHandler: @escaping (CachedURLResponse?) -> Void) {
        print("session:willCacheResponse:")
        completionHandler(proposedResponse)
    }

    func urlSession(_ session: URLSession,
                    dataTask: URLSessionDataTask,
                    didReceive response: URLResponse,
                    completionHandler: @escaping (URLSession.ResponseDisposition) -> Void) {
        print("dataTask:didReceive response")
        completionHandler(.allow)
    }

    func urlSession(_ session: URLSession,
                    dataTask: URLSessionDataTask,
                    didReceive data: Data) {
        print("data = \(data)")
    }
}

With DBDebugToolKit activated

When I first clic on the load button, the request is sent to the server, and the logs are the following :

dataTask:didReceive response
data = 129408 bytes

When I clic a second time, the request is not sent to the server, the cached image is used and the logs are the same.

We can note that the log print("session:willCacheResponse:") is never called even it should be.

The cache folder structure is : Wrong cache structure

Note the duplication of the Cache.db files. What's more the fsCachedData folder, that contains the cached image, is at the wrong location. That means the image is saved in the default URLCache and not in the custom one I defined in my sesssion.

Without DBDebugToolKit activated

If I trash the app and remove the line DBDebugToolkit.setup() in the AppDelegate, when I first clic on the image, the request is sent to the server and the logs are the following:

dataTask:didReceive response
data = 16384 bytes
data = 16384 bytes
data = 16384 bytes
data = 16383 bytes
data = 16384 bytes
data = 16384 bytes
data = 16384 bytes
data = 14721 bytes
session:willCacheResponse:

Note that this time the logs are correct and session:willCacheResponse: is printed !

The cache folder structure is Correct cache structure
This time there is only one Cache.db file, and the fsCachedData folder is under the com.xxxxx.yyyyy directory. Which is the expected behavior.

Issue

So the issue is that a custom url session with a custom url cache is never taken into account with DBDebugToolkit activated. What's more the URLSessionDataDelegate method urlSession(_:, dataTask:, willCacheResponse:, completionHandler:) is not called.

@gamada-de gamada-de added the bug label Jun 29, 2020
@gamada-de gamada-de added this to the 0.6.0 milestone Jun 29, 2020
@felginep
Copy link
Author

felginep commented Feb 8, 2022

Is this resolved ?

@gamada-de
Copy link
Collaborator

Sorry this is currently not solved. This is an bigger problem of this tool how the request will be currently logged/stored. But i hope this can be fixed in the near future with an refactoring.

@gamada-de
Copy link
Collaborator

@felginep Maybe you can check if it is now working correct with the new version. 0.9.0

@gamada-de gamada-de modified the milestones: 0.6.0, 0.90, 0.9.0 Feb 13, 2022
@gamada-de gamada-de linked a pull request Feb 13, 2022 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants