Hi,
I'am a happy user of Ocroprint.
There is only one thing that really annoys me and that is that when I access the Octoprint web interface I quite often have a non working page and have to press F5 before I can use the page. This is due to the caching of the webpage, Is it an idea to shorten the cached time or completly disable the caching or make this adjustible?
When you say "...have a non working page" do you mean that it's missing the stylesheet? You would see everything mostly over on the left as text and raw links. Otherwise, does it tell you anything like "you need to reload" or "OctoPrint isn't loaded yet" or similar?
You didn't mention much of anything about your setup. Is this running on a Raspberry Pi 3B or something else? What is your browser? What version of OctoPrint are you using?
And what makes you think that has anything to do with caching? 
State/show your problem clearly. Don't just interpret what you are seeing and then ask questions related to your interpretation.
I'am sorry my initial post wasn't that much detailed.
Octoprint: Version 1.3.10
OctoPi: Version 0.15.1, running on Raspberry Pi 2 Model B Rev 1.1
Browser: Firefox on Linux Mint Version: 65.0.1 (64-bit)
Firefox for Android Version: 65.0.1
When accessing the webinterface, somtimes it works fine, somtimes it is missing the stylesheet, sometimes it is half loaded.
I think it has something to do with caching by the browser because a F5 always results in a good working web interface. And it keeps working fine as long as I keep the tab open.
Also the problem is not restricted to one setup because I have 2 Raspberry's running Octoprint and they both have the same behaviour.
Personally, I have many setups and they're all Raspberry Pi 3Bs (but I do also test the 3A+ and the 3B+ sometimes). On occasion, I also see the home page and the stylesheet hasn't loaded. I might see that perhaps 5 out of the 100 times I do a first load of OctoPrint's web interface after a reboot or a restart.
There are times when I run a lot of extra things on my Raspberry Pi 3B, though. You could try running your installation in Safe Mode for a couple of days and see if that fixes it. If it does, then start looking at your plugins and try to figure out what might be slowing down OctoPrint from starting up; the harder it works upon startup, the more likely that it could be too busy to deliver the stylesheet.
The Pi 2 Model B appears to have four 900MHz cores. The 3B has four 1.2GHz cores or about 33% faster. And the 3B+ at 1.4GHz would then be 56% faster than what you've got. The faster it is, the less you might see this sort of error, to be honest.
But even past all that, it's about print quality, right? I want my print jobs to come out great and to not waste my time.
FWIW TouchUI is where I see the biggest pain point on this.
I just logged in to start new thread and report my observation and this one popped up at me, which is somehow close to what I wanted to report, so replying here:
I see different behavior when connecting to the same instance of Octoprint with Windows/Chrome and Ubuntu/Chromium.
OctoPrint 1.3.10 running on OctoPi 0.16.0
Access Control: enabled
Ubuntu 18.04.2 LTS / Browser: Chromium Version 72.0.3626.121 (Official Build) Built on Ubuntu
Windows Pro 64bit / Google Chrome Version 72.0.3626.121 (Official Build) (64-bit)
Tried accessing UI by clicking on browser Favorite link and by typing in the IP address directly - the behavior is the same.
In Chromium the page loads with no data, as shown below, and in the background there are several 403 errors that cannot be seen unless you "dive into" developer tools.
When I reload the page with CTRL-F5 the following screen appears:
And then I can log in without issues:
Under Windows OS, clicking on Favorites link or entering IP address takes directly to login dialog (3rd image in this post) and I can log in right away.
So, some kind of caching is involved when accessing from Linux platforms.
As a separate note - we are missing favicon.ico file.
This does not disturb me much as workaround is pretty simple, just wanted to share my observation.
Thanks
Best regards,
Boris
It's possible that different browsers have different tactics for dealing with a website which has a login form and it's not within an SSL context.
I know that when I recently turned on User Access for one of my setups, Safari made very sure I knew that the website sponsored terrorism (or something almost as dire). I then said, okay, I'll try using https://octopi.local and then it was equally dire since it was a self-signed certificate. (Honestly, local self-signed websites should get a Get Out of Jail Free card with respect to these sorts of warnings.) It's almost as if these browser manufacturers make a cut from the digital certificate sales on an annual basis. :eyeroll:
@foosel would probably know more about which browser behaves in what way, though.
That doesn't indicate that it has something to do with caching, that indicates that whatever it is that makes part of the webpage not properly load is intermittent and fixed with a reload. My money would be on a network issue more than anything caching related here (especially since a simple reload doesn't even override the cache).
When it happens the next time, open your browser's debug console and share a screenshot of the console and the network tab. That might give some insight. Also share your octoprint.log and test if the issue persists in safe mode.
This on the other hand indeed does look like a caching issue, especially since a force reload is needed to fix it, and the kind of errors you are seeing indicate that it is serving up old content but the new force login plugin is preventing API access (as it should). Might be something similar to this FAQ entry, so just to be sure try the things outlined in there.
What's interesting is that it only happens on Linux Chromium. I'll have to fire that up somewhere and see if I can reproduce this issue.
No, we aren't. We haven't a favicon.ico file in the root, but we instruct the browser to use a dynamic one defined through page headers. Some browsers are still ignoring those, but the majority aren't, but adding a static one would break the dynamic one. See also the discussion in
FWIW I sometimes get a page without style sheet when connecting to OctoPrint. I, too, had ASSUMED it was some kind of caching issue. This using Safari on a Mac running the latest macOS. However, it may also be related to OctoPrint/OctoPi startup. If my memory is correct (an iffy proposition) the issue only happens on the first connection after booting/re-booting the Pi running OctoPrint.
In case it helps, I've just read where it is suggested that Safari has a default timeout of 60 seconds while awaiting a stylesheet load.
