Hi!
I’m writing again about IE caching ajax queries from MineOS. Can you modify current scripts so that they work in IE? Porbably by adding some HTTP-headers or adding ajax setup (cache: false). I don’t want to change my browser but in IE I have to refresh pages as I’m not sure whether data is actual.
Once I tried adding ajax setup, but as fas as I remember MineOS did not accpet URLs like XXX?timestamp=YYYY so I had to revert this changes.
Just a suggestion, but does it work if you change IE’s settings under “Internet Options”?
Internet Options > General > Browsing History > Settings
Under “Check for newer versions of stored pages”, change it from “Automatically” (the default) to “Every time I visit the page”.
The reason this didn’t work is because there is a 1:1 mapping of JSON keys and method argument names. When you add the $.ajaxSetup({ cache: false }); line, it adds a new argument _ filled with a timestamp. The MineOS functions in mineos.py do not want this argument.
Because any mistakes in implementing this change could affect every MineOS user everywhere, I’m releasing this change as a separate branch. This is the only change on the branch and should you report back it is working as-intended, I can consider merging it into the master branch, making it IE-friendly by default.
See the wiki: no_ajax_caching branch.
cd /usr/games/minecraft
git fetch
git checkout no_ajax_caching
Sorry for the delayed response!
It looks like it works though I’m not sure. Besides it’s not a good idea to change this setting for absolutely all requests.
Yeah, I supposed there is a 1:1 mapping. Is that branch a fuul clone of master + disabled caching?
Effectively, yes. Except that I made a tiny change to the main branch for stock_profiles 1.8.1 that you won’t have yet, but will have, provided that it works as expected.
Let me know what browsers you’re using when you deem it working correctly–I only have IE11, Chrome and FF available to me.
Ok, I’ll try. I’m using IE 11 for the last monthes. Also I have Chrome.
When I tried to find a solution I found that (if I don’t mistake) this is mainly a problem of IE and FF.
By the way, is there better (smarter) solution instead of fake timestamp? I saw some solutions like using headers. For instance, Cache-Control or Expires, probably something else. Isnt’ it better?
According to jQuery, the best solution is the appending of a real timestamp (it’s not fake, by any means)–or at lesat that is the best solution they have implemented officially for preventing ajax caching.
But, ultimately I agree with you–using the HTTP headers is better, and I reverted my most recent change and replaced it with the appropriate server-side headers.
git fetch
git pull
Seems to be working as intended, let me know if it works fine on your end!
Where should I check it? In master branch or no_ajax_caching?
These changes are still in no_ajax_caching, yes.
Ok, I’ll check it a bit later
It looks like it works but I’ll check once more time later. There are 2 problems:
So that chart is being drawn by 2 threads.Also I did not check everything but I mainly checked overview. Usually caching was very obvious exactly here. Unchanging chart, permanent values for CPU/memory/HHD etc. Now it’s chaning with every click.
This is unrelated to the changes in the ajax-caching, and exists even in the master branch. The chart gets refreshed at once per two seconds. Each time you click server overview, it starts a 2 second interval to refresh the chart. If you click it 5 more times (while remaining on the server overview), it’ll start 5 new intervals to update it.
All intervals are removed if you spend 2 seconds on any other pane (because the intervals die if the overview is not the current page). For technical reasons, it’s not a second thread, just a second interval (JS in most implementations will run single threaded)–so any slowdowns are client-side, not server side.
I don’t think you should be getting a 304 anyway–at least not on these calls. I think if IE were really doing its job properly it should instead have no HTTP request and report “(cache)”. All calls that come to the server will always return 200, that is the design of the Cherrypy webserver MineOS runs on.
IE makes things difficult because it decides on behalf of the user that the data it already has is good enough to refresh with–MineOS knows that all requests need to be regenerated so 304 would never occur–200 or bust.
Yes, I understand this is not a problem at all and moreover it’s not a problem of ajax. I just wanted to ask whether there is a solution like named timers or something else. However I suppose you didn’t write chart code yourself, I suppose it’s some ready solution, some ready component in the form of several js-scripts. And it would pe a problem to “hack” them.
I remember that eralier IE actually displayed 304 code for ajax requests (like loadavg for chart). I don’t know why it shows 200 now, probably it was some update for developer tools, but earlier it definitely returned code 304. And as far as I remember from posts that I read excatly this was the problem of IE: in case of ajax request IE cached them and in the case of repeated requests IE even did not try to send a request to the server. It just returned 304 code with the request time less than 1ms. Here is one of this articles: Internet Explorer's Ajax Caching: What Are YOU Going To Do About It?
Ah, IE9 really did return 304? Yuck. That is perhaps the least intuitive debugging tool possible, then, as one could realistically think to go to the server-side and debug why it was returning 304, when it was instead being not contacted at all. I figured that at least with its current behavior–reporting (cache) that it would not send people on wild goose chases. IE never ceases to amaze me–and it’s things like this that made it the most obvious choice in the world for me to have left it and never looked back!
This is actually by my design–because it was the best I could come up with at the time. However, I don’t really see it as a pressing problem. In the worst case scenario, the webui client is making a 2-3 requests per second for a server that can certainly handle ten times as much.
True, this does allow runaway usage, if one were to constantly click overview over and over and over though we’re addressing right now the only reason a user would do it, by fixing the IE-only caching issue. Should a user ever go to any other page (and I think they would), any runaway problem will immediately cease, too.
I designed it like this because more than 90%+ of the use of the web-ui doesn’t involve the dashboard–people are doing other tasks, so it made sense to not have on-going timers on all other pages. With the fix we’re doing now, we’ll see if there are any other issues with this design or if it will be found rather innocuous overall.