Very vague possibility of a bug report. After I upgraded to a new 2020-02-xx version of Johnson’s custom firmware now with a vastly enhanced multi-graph web UI as opposed to the 2018-10-xx single graph version I had been using before I got very confused because it looked like the upgrade had failed. I couldn’t see the new sophisticated web UI, I was still seeing an old-style web page but digging around in the ZyXEL admin web-UI’s menus I could see the new expected version string. I tried all sorts of things floundering. Then I discovered that it was simply a matter of stale cached content in the browser. Somehow getting the browser to really refetch the latest page at
http://192.168.3.1:8000 was all that was needed to reveal the new style stats server’s numbers page finally.
Apologies if all the following is old news to you, which I’m sure is probably the case, but just in case it’s useful, here goes:
So it looks to me as if the cache control info is wrong. See
https://www.mnot.net/cache_docs/#SCRIPT In fact the whole article if you’re not au fait with web cacheability and caching-friendliness. It looks as if there is caching of stale data going on within the browser here, and I’m guessing it’s because because cacheability headers are missing.
It would be a really bad thing to try and disable all caching by fighting the browser, I recommend the best thing to do is to add
Etag http headers to the generated web pages. (See above url.) A good web server will do this for you when it can and I’m assuming that Mongoose (is that right) will do so but only when it
can, and here you’re taking generated content produced by an application and turning it into web pages, not serving up files from the file system and so in this case webserver engines need to be told what to do as they can’t generate cacheability headers automatically from metadata about a served-up content file’s size, last-modified date and even a hash of the file content. I have written this kind of code in a server-side module before. Again, the best thing would be to add ETag headers whose values are cheapo cheapo hashes (ie fast and not cryptography-grade) of the entire generated data itself which is the content of your webpage. That way the browser will know when the content of the web page has changed because the etag hash will change and if the value is not changed then the browser can skip a repeat download. The system is then bomb-proof and there’s no fiddling about with a guess about freshness times.
In this case the problem was I assume the reverse, if my guess/diagnosis is right, in that old information which was stale was regarded as good by the browser either because there was no cacheability header information published by the web server or else the cacheability headers were wrong, which is unlikely unless there was a definite bug. When the content of the page changes then the ETag value computed from the page content, which is the cheap and fast hash, becomes different from the ETag value last seen by the browser and so the browser knows to do a download. Since the browser, so it seems, was unwilling to download the page in question (in this case ":8000/") even though the relevant page content had in fact changed inside the server my guess is that there were no ETags. Maybe there is an overall default in force for a long cache time which is totally inappropriate here.
I think back then I was still seeing the browser’s cache which contained a webpage produced by the old firmware and the browser was ignoring the fact that the content of "/" was by then different on the server. The server presumably got a get http head request or got a
conditional get which returned
not_modified. There are various
if-modified queries and conditional requests, which check dates if applicable, or else ETag values, if not using dates in cacheability headers, as here, with non-(static)-file content being served up.
Hopefully that’s all you have to do. One albeit long line of code. I had to do a lot more than just adding calculated ETag headers in the server application code but my circumstances were different.