Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement better cache busting for new releases #11

Closed
mrdavidlaing opened this issue Jun 9, 2014 · 10 comments · Fixed by #12
Closed

Implement better cache busting for new releases #11

mrdavidlaing opened this issue Jun 9, 2014 · 10 comments · Fixed by #12
Assignees

Comments

@mrdavidlaing
Copy link

@mrdavidlaing, we should discuss putting kibana's assets in a versioned directory or using a cache-busting query param to avoid https://www.flowdock.com/app/cityindexlabs/cityindex-logsearch-io-support/inbox/341753
dpb587 17:48
@mrdavidlaing, we should discuss putting kibana's assets in a versioned directory or using a cache-busting query param to avoid https://www.flowdock.com/app/cityindexlabs/cityindex-logsearch-io-support/inbox/341753
dpb587 17:48
perhaps angular has a built-in way to do that which we can embed into our config.js? /cc @ryanholder
dpb587 17:49
aka, i don't know where to create such an issue
ryanholder 18:08
@dpb587, if I remember correctly Kibana uses RequireJS for assets and the issue might lie there. This is the first thing on Google regarding cache busting for RequireJS - http://requirejs.org/docs/api.html#config-urlArgs
dpb587 18:12
For our kibana deploy, we should consider renaming /app/ to /app-$BUILD_NUMBER, updating index.html, and set long-term caching for that directory. The require.js urlArgs is a hacky approach and avoids any sort of useful caching.

@mrdavidlaing mrdavidlaing self-assigned this Jun 9, 2014
@mrdavidlaing
Copy link
Author

screen shot 2014-06-09 at 18 47 13

@dpb587
Copy link

dpb587 commented Jun 10, 2014

I misspoke when I said urlArgs was a hacky approach - that was based solely on the docs example of using it with a dynamic (new Date()).getTime(). Sorry for that confusion and glad you PR'd the better implementation.

@mrdavidlaing
Copy link
Author

I'm still confused why urlArgs was committed upstream commented out - want to know if that was intentional before accepting this as a fix - elastic#1291

@mrdavidlaing
Copy link
Author

If I only had a 💵 for every time I've been bitten by caching issues...

@ghoranyi
Copy link

Actually I am trying to upgrade from 3.0.1 to 3.1.0 and I still have caching issues. I still receive old resources, served from browser cache, so I am not sure, that is issue should be closed.
image

@mrdavidlaing
Copy link
Author

@ghoranyi - have you applied the urlArgs patch?

You should be seeing url's like this:

image

@ghoranyi
Copy link

@mrdavidlaing No I didn't, but I will do so. I just used the version available at elasticsearch.org. Thank you for your quick response.

@mrdavidlaing
Copy link
Author

Please - let us know how you get on.

If our patch works for you; would you consider creating an upstream PR to get it applied to elasticsearch/kibana ?

@ghoranyi
Copy link

@mrdavidlaing Yes it worked, indeed. I will create the upstream PR as soon as I can (I have some other pending changes, which I am currently discussing with my employer - licensing, etc...)
Thank you for the help again.

@mrdavidlaing
Copy link
Author

Great news - glad our fix helped you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants