Clients are currently caching the proxied application because it has a very stable URL. This is actually a bad thing, since not only will the application be changing once it is under test, but the script that we inject will be a pointer to a potentially stale harness.js
I came across this when extracting the agent server, and the port on which the harness was changing, but we ended up using the old document that pointed to an old harness.
This will only become more pronounced once we move over to running the agent server on a bunch of different ports inside of a bunch of different projects.
Approach
I tried setting a Cache-Control: no-cache header on the proxy response, but couldn't get it to stop caching, so this contains a brute force approach of just adding a cache-busting timestamp to the proxy server url.
Maybe we should take another look at this together on wednesday. It would be much better to figure out the correct cache header combination, rather than this brute-force approach, imo.
Motivation
Clients are currently caching the proxied application because it has a very stable URL. This is actually a bad thing, since not only will the application be changing once it is under test, but the script that we inject will be a pointer to a potentially stale
harness.js
I came across this when extracting the agent server, and the port on which the harness was changing, but we ended up using the old document that pointed to an old harness.
This will only become more pronounced once we move over to running the agent server on a bunch of different ports inside of a bunch of different projects.
Approach
I tried setting a
Cache-Control: no-cache
header on the proxy response, but couldn't get it to stop caching, so this contains a brute force approach of just adding a cache-busting timestamp to the proxy server url.