How best to defeat browser caching when requesting Activity Profile

[uglycoyote]

I am trying to develop something where different users, running the xAPI package that I am developing, communicate information through a shared document using the Activity Profile. (a sort of a shared "leaderboard" for competition, similar to the Tetris sample from xAPI.com

I'm running into issues where, when calling retrieveActivityProfile, the response is returning Chrome's cached version of the response, rather than sending the response to the server.

I have tried to remedy this problem by adding extra headers

export const cacheDefeatHeaders = {
    'Cache-Control': 'no-cache, no-store, must-revalidate', 
    'Pragma': 'no-cache', 
    'Expires': '0'
};

and passing this in as the cfg.requestHeaders to the call. but that hasn't made a difference, and after reading more about those headers, I'm now under the impression that those are more supposed to be headers that the server includes in the response, in order to tell the client browser not to cache. I don't have control over the server's response though (it is a commercial LMS) so I cannot include the no-cache headers into the server's response.

It seems like the common way of defeating the cache from the client perspective is just to do something to ensure that the URL is different each time, such as including a timestamp into the query string. But I'm not sure if TinCanJS provides a way to do this from the retrieveActivityProfile query.

I can see that under the hood, the sendRequest function that retrieveActivityProfile calls allows for passing an arbitrary collection of URL query parameters, but at the top level call, there doesn't appear to be any way to pass extra parameters or otherwise configure retrieveActivityProfile to add something like a timestamp into the URL.

Is there a recommended approach in TinCanJS to force the request to go through to the server and not use the browser's local cached version?

[garemoko]

I'm curious if you're seeing this behaviour with other LRSs?

[uglycoyote]

@garemoko I'm only really using the one LRS (CornerStone OnDemand) so I don't know whether it's a problem with others. I think it's entirely just a question of what headers are served up with the responses to the queries.