Stacks.js: Set header `Cache: no-cache` to fix caching issues

[yknl]

With the latest collection changes in blockstack.js, we came across some caching related issues which saw stale data being returned from a getFile request. One potential solution is to set the Cache: no-cache header.

[reedrosenbluth]

@yknl Can you give me some more detail on the collection changes that caused these issues?

[reedrosenbluth]

@zone117x and I think that the cache-control directive needs to be set in the server's responses, rather than client side, since the specifying it as a header causes a CORS error, and specifying it as a fetch option doesn't seem to do anything (the browser likely just ignores it to avoid showing the CORS error)

[yknl]

How do you recommend we go about doing that since the Gaia hub is not involved on the read requests.

[zone117x]

The gaia hub has a config option for cache-control that all of the backend drivers currently support. E.g. the Azure blob upload function can specify a cache-control response header.

The PBC hub currently has this set to public, max-age=1, which is a strange cache configuration, and seems to explain the flakiness during testing.

There does not appear to be a reasonable client-side way to override this, due to the CORs simple requests rules -- note the lack of any cache headers in the CORs GET request safelist.

There are some hacky cache-busting techniques, like appending a ?nope=${Date.now()} to the GET request URL, but I think we should first explore the PBC hub cache config setup first.

@wileyj suggests we get feedback from @kantai on why we are currently using this cache config.

[zone117x]

@reedrosenbluth @yknl the staging hub https://collection-hub.blockstack.org now has the cache-control: no-cache response header. You should see the header for newly updated files.

I did some preliminary testing with my own sample app, and an unmodified blockstack.js. Chrome's network devtools show the response payload sizes which indicate that the caching is working as intended.

• First request fetches a file for the first time -- see 1.9MB response size and >200ms request time
• The next two requests are for the same, unmodified file. The cache appears to be used -- see 65B response size and ~100ms request time.
• Then uploaded a different image with the same file name, using a different browsing context.
• The fourth request is after this, and the new file is correctly fetched -- see 2.4MB request size and >200ms request time.
• Last two requests are correctly using the cached 2nd file.

@reedrosenbluth Can you test if the caching bug is fixed in the collections sample app when using the staging hub?

[reedrosenbluth]

The contacts app's cache behavior appears to be working great with the newly updated collections staging hub. Response headers contain the no-cache directive and no stale data is being presented 😄

[johannesjo]

I am still experiencing this for https://gaia.blockstack.org//hub/xxx. The header is still cache-control | public, max-age=1