URL cache policy in iOS – NSURLRequestCachePolicy

NSURLRequestCachePolicy has recently been set incorrectly, resulting in a number of bugs in the version. Here we investigate NSURLRequestCachePolicy

NSURLRequestCachePolicy is defined as follows

typedef NS_ENUM(NSUInteger, NSURLRequestCachePolicy)
{
    NSURLRequestUseProtocolCachePolicy = 0,

    NSURLRequestReloadIgnoringLocalCacheData = 1,
    NSURLRequestReloadIgnoringLocalAndRemoteCacheData = 4, // Unimplemented
    NSURLRequestReloadIgnoringCacheData = NSURLRequestReloadIgnoringLocalCacheData,

    NSURLRequestReturnCacheDataElseLoad = 2,
    NSURLRequestReturnCacheDataDontLoad = 3,

    NSURLRequestReloadRevalidatingCacheData = 5, // Unimplemented
};Copy the code

• NSURLRequestUseProtocolCachePolicy default cache strategy, its behavior is appointed by the agreement on the best way to implement the agreement. An introduction to this strategy is detailed later in this article.

• NSURLRequestReloadIgnoringCacheData load data from the service end, completely ignore the cache.

• NSURLRequestReturnCacheDataElseLoad cache data, ignoring its expiration time; Data is loaded from the source only if there is no cached version.

• NSURLRequestReturnCacheDataDontLoad using only the cache data, if there is no cache, the request failure; Offline mode when no network connection is established

NSURLRequestUseProtocolCachePolicy implementation mechanisms

Apple officially provides the following decision tree:

NSURLRequestUseProtocolCachePolicy for HTTP and HTTPS decision tree

As can be seen from the figure, the simple process is as follows:

1. If the cached response to the request does not exist, the URL loading system loads the data directly from the source.
2. Otherwise, if it is not explicitly stated in the cached response that each request must be revalidated, the URL loading system will return cached data if the cache of the response is not expired
3. If the cached response expires or needs to be revalidated, the URL loading system sends itHEADRequest to the source to see if the resource has changed. If it does, the URL loading system retrieves the data from the originating source. Otherwise, it returns the cached response.

Cached responses expire or need to be revalidated

The expiration of cached responses or the need for revalidation can be determined by the HTTP request and response headers

• Cache-Control
  
  On the first request to the server for a resource, the server uses the cache-control response header to specify the Cache policy in the following format: cache-control :max-age= XXXX. This header specifies when the Cache will expire
  
  Cache-ControlHeaders have the following options:

• Expires Expires indicates an expiration date that allows a client to not check (send a request) before that date, equivalent to max-age. But if both exist, they are overwritten by the max-age of cache-control. Example: Expires: Thu, 01 Dec 1994 16:00:00 GMT (must be in GMT format)

• Last-modified/if-modified-since last-modified is a response header returned by the server indicating when the resource was Last Modified. If-modified-since is sent by the client to indicate when the resource was last Modified, as recorded by the client. When the server receives a request with this header, it compares the time with the last modification time of the resource. If the resource has not been modified, it directly returns HTTP 304 instead of the package body, telling the client to use the local cache directly. Otherwise respond with the full message content.

• Etag/ if-none-match Etag is sent by the server to indicate the unique identifier of the resource on the server. When a client requests a resource that has expired (using cache-control max-age) and is found to have an Etag statement, the client requests the server with if-none-match headers. After receiving the request, the server compares it with the resource identifier and decides to return 200 or 304.

Reference:

• NSURLRequest
• Caching in HTTP