Networking on Android doesn't use Cache

[andon]

The HTTP Client on Android (OkHttpClient), that is used for networking, doesn't have cache, so Cache-Control headers are not respected.

Is this a bug report?

Yes

Have you read the Contributing Guidelines?

Yes

Environment

Environment:
OS: macOS Sierra 10.12.6
Node: 8.9.0
Yarn: 1.3.2
npm: 5.5.1
Watchman: 4.9.0
Xcode: Xcode 9.0.1 Build version 9A1004
Android Studio: 3.0 AI-171.4408382

Packages: (wanted => installed)
react: 16.0.0 => 16.0.0
react-native: ^0.50.1 => 0.50.1

Steps to Reproduce

If you use fetch to perform a request, and the response has Cache-Control headers, then they should be respected. For example, if the response has the Cache-Control: max-age=60 headers, then, after a successful request the response should be cached. Subsequent requests in the next minute should serve the content from cache.

1. Perform sequential requests for resource that has cache control set
2. Check the response to realize if it came from the device http cache or the server was hit

Expected Behavior

Cache headers should be respected and subsequent requests should be served from the cache.

Actual Behavior

On iOS cache headers are respected and responses are served from the cache when necessary.
On Android cache headers are not respected and server is always hit.

Reproducible Demo

Server app that returns a random number between 0 - 100. It sets cache-control header:
https://github.com/andon/cache-tester-server/blob/master/index.js
https://evening-temple-40153.herokuapp.com/route/random

React-Native App that targets the server app and can be used to showcase the different behaviour on iOS and Android:
https://snack.expo.io/SJJLdpBkz

[andon]

The issue is in the https://github.com/facebook/react-native/blob/1e8f3b11027fe0a7514b4fc97d0798d3c64bc895/ReactAndroid/src/main/java/com/facebook/react/modules/network/NetworkingModule.java

Where the client is created, a cache is never configured:
https://github.com/square/okhttp/wiki/Recipes#response-caching

[tunatoksoz]

It almost sounds it'd be useful for everyone to be able to configure okhttp client.
It used to be the case that replacing the default client would work, but after [1], this ability is gone.

I think a way to customize the okhttp client is crucial for certain set of applications, such as 1. self signed certs, customizing caching, certificate pinning, etc.

[1] 0a71f48#diff-f8703d50cf5af4c06824e2928dddb500

[tunatoksoz]

I used reflection to mitigate this.

[andon]

We do the same thing as well.

I also totally agree that configurable OkHttpClient is extremely useful and very unfortunate that it has been broken. There are already PRs for that:

• Allow app to init an OkHttpClientProvider.IProvider with custom settings(FrescoModule and NetworkingModule) #14675
• Inject configured OkHttpClient to networking module using MainPackageConfig #14068

Even without that, I still think that having cache is a must on Android, to at least align with the behavior on iOS (and everything else for that matter 😄). Such a change would require just initializing the cache:

private OkHttpClient createClient(ReactApplicationContext context) {
    return OkHttpClientProvider.createClient().newBuilder()
        .cache(new Cache(new File(context.getCacheDir(), "rn-http-cache"), 50 * 1024 * 1024))
        .build();
  }

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Maybe the issue has been fixed in a recent release, or perhaps it is not affecting a lot of people. If you think this issue should definitely remain open, please let us know why. Thank you for your contributions.

[simonracz]

I think this is important.

[stale]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may also label this issue as "For Discussion" or "Good first issue" and I will leave it open. Thank you for your contributions.

[stale]

Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please feel free to create a new issue with up-to-date information.