Direct answer
No. In Titanium SDK 7.x and 8.x, cacheEnabled does not enforce Cache-Control max-age, no-cache and must-revalidate identically on iOS and Android. Enforcement is delegated to the native platform stack, so behavior is platform-specific and OS-version dependent. cachePolicy acts as a higher-level override that can supersede Cache-Control parsing when set. The process-wide cache is shared across all HTTPClient instances with no SDK-level isolation and eviction is handled by the native layer.
Confirmed facts
- HTTPClient cacheEnabled stores responses in a local file cache keyed by URL and request headers.
- The cache is shared across all HTTPClient instances within a process.
- SDK 7.x and 8.x release notes reference stale cache fixes on iOS and regressions reported on Android 12.
- cachePolicy is accepted as a parameter and its interaction with Cache-Control is undocumented.
- No official test suite validating HTTP spec compliance is published for these SDK versions.
Likely explanation, not confirmed
Implementation is expected to delegate to native stacks. iOS uses NSURLSession / CFNetwork. Android uses the native HTTP engine available to the Titanium runtime, historically HttpURLConnection and in later builds OkHttp. That delegation means Cache-Control parsing follows platform rules, not a unified Titanium implementation.
On iOS, URL Loading System generally processes max-age, no-cache and must-revalidate strictly, with conditional GET using If-Modified-Since / If-None-Match when appropriate. On Android, interpretation varies by OS version and underlying engine. Android 12+ has been reported with regressions around stale-while-revalidate and max-age handling compared to iOS.
cachePolicy is likely evaluated before native caching. Values such as reload-ignoring-local-cache or return-cache-data-dont-load are expected to override header directives. Exact precedence is undocumented and may change between SDK minors.
Isolation and eviction are platform managed. The shared process cache is a flat-file or SQLite store managed by the native OS. Eviction is expected to follow platform LRU and storage pressure policies, not SDK-configurable TTL or size limits. No per-instance isolation is provided.
Practical verification steps for this case
- Enable cacheEnabled true and set a known max-age response. Record first request time and second request time within max-age. Use a proxy to confirm whether a network request is made or served from disk.
- Serve a response with Cache-Control: no-cache and must-revalidate. Check via proxy if a conditional request with If-None-Match / If-Modified-Since is sent on iOS vs Android.
- Set cachePolicy to reload-ignoring-local-cache while max-age is still valid. Verify server receives a request regardless of headers.
- Test two HTTPClient instances with different headers to the same URL. Observe shared cache hits to confirm lack of isolation.
Assumptions: SDK 7.x and 8.x as stated, default native engines, no custom Titanium modules altering networking. Behavior is highly dependent on OS version, not only SDK version.
One missing diagnostic detail that changes recommendation: which native HTTP engine and OS version are you testing on Android for your build. OkHttp vs HttpURLConnection and Android 12+ vs earlier changes the expected Cache-Control handling and the workaround needed.
titaniumsdk