Chrome caching all endpoints on a prescribed port

49 Views Asked by At

I'm spinning up an API server locally, and serving it on port 8000. All seems good, and the response reflects what is in the code / expected.

I then make a change, and the API response does not change. These are the request/response headers supplied:

enter image description here

Is this a new feature in Chrome? Should I switch to Chromium for a better DX?

The caveat that seems to skirt this issue, is changing the port number every time I change the underlying response of the API. However, this to me is as annoying as it is time costly.

I'm regenerating the Swagger documentation before reloading the server, but the changes do not show. This issue is also reflected on the JSON responses of the endpoints themselves, so it feels like there is some aggressive caching going on.

Port 9892 (this page could be reloaded, hard reloaded and everything in between, but nothing changes):

enter image description here

Port 9893 (showing a minor change):

enter image description here

What have I done wrong?

1

There are 1 best solutions below

2
tom redfern On

Is this a new feature in Chrome?

I don't think so.

The server is sending a Cache-Control: no-store header with the response. By sending this header, the server is telling chrome not to cache the response locally and to always go the server for the current representation of the data.

So, for chrome to suddenly started caching responses would mean that chrome was no longer obeying this header.

Furthermore, chrome is sending a Cache-Control: no-cache header with the request. By sending this header, chrome is telling any intermediaries between itself and the server which may have a copy of the response not to return it - however this is probably inapplicable in your local set-up.

I then make a change, and the API response does not change.

I think what is likely to be happening is on the server-side rather than on the client side.

For some reason when you make a change the API backend application state as it exists in memory doesn't get unloaded/reloaded and therefore continues to serve the same response as before you made the change, but when you cycle the port number then the host process has no alternative but to unload/reload the application and therefore the content changes.

What have I done wrong?

I don't think this is something you have necessarily done wrong and maybe there are a number of issues here, but I think if you want to fix this you need to work out how to make your API app unload its working memory when you make a change (other than by changing the port number). Perhaps recycling the host process directly?

But regardless, this is nothing wrong with chrome :)