Default cacheControl policy about ember-cli-deploy-s3-index

[LevelbossMike]

Did you encounter this as a problem with s3-index specifically or did you see that with other resources?

[dcyriller]

I think the only issue was with index.html file. But as the other assets loading is done thanks to index.html file, I can't tell for sure.

[LevelbossMike]

So you had issues due to the cache header? And these issues were fixed due to cache-control = private, no-store? What behavior did you encounter that was not what you expected? I have been using the addon on multiple projects and I can't remember I ran into issues - that's why I am asking.

Of course you can always customize this value via the cacheControl-option

[dcyriller]

Yes, I've had some issues with this cache header. The index.html was not refreshed but served from the cache when typing the app's root url in Chrome / Firefox adress bar. Note that there was no issue when typing myapp.com/signin. Typing an other url than the root one would refresh the index.html.

Setting the cacheControl to private, no-store fixed the issue. I've opened a PR to update the default cacheControl. Feel free to accept / close it.

[LevelbossMike]

So you updated the index-file, activated it and then you didn't see the new version because it was served from the cache?

I have not encountered this and I'm a bit reluctant to change the default as nobody encountered an issue like that so far as far as I can tell. Can you walk me through what you did when you encountered the issue?

I would assume that checking if the version to serve exists in the cache and then serve it would be desired behaviour instead of redownloading it every time no matter what.

Private also isn't really something that everybody needs as you would normally serve the same version to all your users when using s3-index.

Can you please elaborate some more why you fell the suggested change is better than the existing default?

[dcyriller]

So you updated the index-file, activated it and then you didn't see the new version because it was served from the cache?

I did it again and I have to say I misunderstood the meaning of the 304 HTTP reponse. As long as the new index-file is not activated, I get 304 reponses. When it is activated, I properly get a 200 reponse.

I would assume that checking if the version to serve exists in the cache and then serve it would be desired behaviour instead of redownloading it every time no matter what.

I understand what you say. I have been confused by the 304 response code. I thought the network request had not hit cloudfront to check index-file validity but had served index-file from the cache right away. It turns out I was wrong: the network request first hit cloudfront then serve index-file from the cache. If any new index-file is referenced, I should get a 200 response.

False alarm. Sorry for that and thank you for your answers.