NSURLConnection, NSURLRequest and Remote Caching

Question

I am having a slight problem with query caching using asynchronous NSURLConnection connections on iPhone. I don't know if I misunderstood something, or if Cocoa does the opposite of what it should do ...

The documentation for NSURLRequest says that:

NSURLRequestReloadIgnoringLocalCacheData p>

Indicates that the data to load the URL should be loaded from the source. Existing cache data should not be used to satisfy the URL load request.

and

NSURLRequestReloadIgnoringLocalAndRemoteCacheData p>

Indicates that not only local cache data should be ignored, but also that proxies and other intermediate products should be instructed to ignore their caches as far as the protocol allows.

Now, if I send NSURLRequest with NSURLRequestReloadIgnoringLocalCacheData (which should ignore the local cache, but use the remote cache, if available), the headers sent:

 GET / dashboard HTTP / 1.1
 User-Agent: XBlip1.0 CFNetwork / 422.15.2 Darwin / 9.6.0 (i386) (iMac8% 2C1)
 X-Blip-Api: 0.02
 Accept: application / json
 Authorization: Basic (...)
 Accept-Language: en-us
 Accept-Encoding: gzip, deflate
 Connection: keep-alive
 Host: api.blip.pl

And the status is 200 OK. But if I use NSURLRequestReloadIgnoringLocalAndRemoteCacheData, which should ignore both local and remote caches, as the name suggests, another header is added:

 If-None-Match: "d751713988987e9331980363e24189ce"

And answer 304 is not changed. I checked the HTTP RFC, and for "If-None-Match" it says that:

If any of the entity tags corresponds to an entity tag of an object that would be returned in response to a similar GET request (without an If-None-Match header) on this resource, (...), then the server SHOULD NOT execute the requested method (. ..) Instead, if the request method was GET or HEAD, the server SHOULD respond with a response of 304 (Not Modified)

Therefore, it seems that if I use NSURLRequestReloadIgnoringLocalAndRemoteCacheData, instead of ignoring the remote cache, Cocoa explicitly tells the remote server that it should use the remote cache, and if I use NSURLRequestReloadIgnoringLocalCacheData, it does not add this line and the actual remote cache is not used.

So what is going on here? Am I missing something or is Cocoa setting the wrong header?

Answer 1

From the documentation:

Indicates that not only local cache data should be ignored, but also that proxies and other intermediate products should be instructed to ignore their caches as far as the protocol allows.

From NSURLRequest.h (10.5 SDK)

Indicates that not only local cache data should be ignored, but that proxies and other intermediate products should be instructed to ignore their caches as far as the protocol allows. Unrealized.

Note the difference: Not implemented

Time for error reporting ...

Answer 2

By adding the NSURLRequestReloadIgnoringLocalAndRemoteCacheData parameter, you instruct the local cache and any proxies that can process the request between your client and the target server so that they do not return their own version of the response data. I think the key component here is that RemoteCache will most likely be a proxy server, and you simply determine that the request should always reach the real server, not the proxied copy.

By adding the "silly-long" parameter, you indicate that your application already has a previous copy of the request, and therefore it is only interested in actually receiving data from the server if it has changed, so you get a "304 Not Modified" response from the server.

This behavior seems counterintuitive, since you explicitly instruct the client not to use their own cache, which would imply that you would want to drop something there and, of course, would not use it as a reference for any subsequent requests. I believe that advanced cache options are provided to allow the developer to process their own cache level, i.e. be notified if the data has not been updated on the server so that they can avoid unnecessary reprocessing.

Answer 3

Pay attention to the proxy and other intermediate elements . You avoid caches that do not reside on the source server. The source server can still return 304.