browsing is caching too hard

[cpg]

I have verified that once a folder is read, it's cached for a long time (forever?) even with a pull-down-to-refresh.

There isn't even an attempt to contact the server with an etag to see if the content changed. The folder appears permanently stuck.

It still happens even if the app is dismissed an started over.

[csoni111]

iOS has inbuilt mechanism for maintaining cached responses. As per the documentation here, there are four options for specifying cachePolicy for any URLRequest in ios.

Cache policy	Local cache	Originating source
reloadIgnoringLocalCacheData	Ignored	Accessed exclusively
returnCacheDataDontLoad	Accessed exclusively	Ignored
returnCacheDataElseLoad	Tried first	Accessed only if needed
useProtocolCachePolicy	Depends on protocol	Depends on protocol

The default one is useProtocolCachePolicy defined here:

Things to note here:

• The Require revalidation every time? step is triggered only when the response sent by server contains the following header with value as Cache-Control: must-revalidate.
• Client issues a head request with If-None-Match header with etag value from previously cached response and the server should respond with 304 Not Modified if the etag matches.

Both of these things are missing in the pfe server.

[csoni111]

The main site api sends response with two important headers for cache:

• Cache-Control → max-age=0, private, must-revalidate
• Etag → W/"d53ecabc251f7afb00478e9e1b70354a"

Also it responds to HEAD request with 304 Not Modified response, if If-None-Match header is sent with the previous Etag value. But the pfe server sends only the Etag header and no Cache-Control header.
So cache mechanism works while fetching the hda server list but does not work while fetching the directory listing inside a hda's share.

To follow the protocols and work as per http specs, we must add Cache-Control header in the response from pfe server and also add response for HEAD request.
OR
The other solution is: we can write our custom code to take care of all this in swift.

[cpg]

The situation happens just the same with the local server, near as I can tell.

The server does NOT seem* to receive any calls for a folder that got recently.

Any changes are not seen, even with a pull-down-to-refresh.

[*] I say seem because I am not sure if calls that are received but handled through caching mechanisms are logged in the local server log (/var/log/amahi-anywhere.log). However, the client still sees folders that are deleted, no updates to the sort order when one folder is touched, etc.

[cpg]

Ok, so the Cache-Control header is not too brute force, and in fact, I checked that it will re-issue calls each time (including pull-down-to-refresh), though they appear to be GETs not HEADs by looking at the logs, and if there is no content changed, it will make the AA server return 304s.

My bad.