Resolving iOS SSO QR Code Login Failures: Redirects, 404 Errors, and NSURLCache Management
This article analyzes why an iOS SSO QR‑code login sometimes fails with a 404 error despite being on company Wi‑Fi, explains the 301 redirect caused by network restrictions, and provides a step‑by‑step solution using NSURLCache inspection and cache‑clearing techniques.
The project includes an SSO QR‑code login that only works on the corporate network; users on public networks receive a failure message prompting them to connect to company Wi‑Fi or VPN. Occasionally, even on Wi‑Fi with good connectivity, the login still fails, but reinstalling the app resolves the issue.
Initial debugging showed that the failing request returned a 404 and that the original POST request was transformed into a GET with a changed Content‑Type. Packet captures revealed a 301 redirect when the request was made from the public network.
Further captures confirmed that the redirect occurs before the request reaches the backend, matching known Nginx redirect issues that can be mitigated by switching to HTTPS. However, after switching to HTTPS the problem persisted, indicating the redirect was not the root cause.
Eventually, a public‑network capture displayed a 301 redirect followed by an HTTP 404, suggesting a cached redirect response. The team added an AFNetworking redirection block to log the original response:
[self.manager setTaskWillPerformHTTPRedirectionBlock:^NSURLRequest * _Nullable(NSURLSession * _Nonnull session, NSURLSessionTask * _Nonnull task, NSURLResponse * _Nonnull response, NSURLRequest * _Nonnull request) {
NSHTTPURLResponse *res = (NSHTTPURLResponse *)task.response;
NSLog(@"Original status: %zd", res.statusCode);
NSLog(@"Original headers: %@", res.allHeaderFields);
return request;
}];The logs confirmed that the 301 redirect was cached, causing subsequent requests to reuse the redirected URL and still receive a 404.
Investigation with the backend team revealed that SSO QR‑code login is intentionally restricted to the internal network; public‑network DNS resolution falls back to a wildcard entry that issues the 301 redirect.
Since the issue stems from client‑side caching, the solution focuses on NSURLCache. iOS uses NSURLCache for both memory and disk caching; POST requests are not cached, but GET requests are. The default cache sizes are 512 KB memory and 10 MB disk.
Cache details can be printed with:
NSLog(@"diskCapacity = %ld", [NSURLCache sharedURLCache].diskCapacity);
NSLog(@"memoryCapacity = %ld", [NSURLCache sharedURLCache].memoryCapacity);Key HTTP cache‑control headers (Cache‑Control, Expires, Last‑Modified, ETag) and their effects are described, emphasizing that Cache‑Control max‑age overrides Expires.
NSURLCache stores its data in the app sandbox at /Library/Caches/ /Cache.db . The database can be inspected with tools like Navicat Premium, examining the curl_cache_response table.
To prevent the cached redirect from persisting, the final fix clears the cache before making SSO QR‑code requests:
[[NSURLCache sharedURLCache] removeAllCachedResponses];Author: Lü Panpan, iOS developer at Yiche, responsible for the Easy Shark app.
Yiche Technology
Official account of Yiche Technology, regularly sharing the team's technical practices and insights.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.