BasicUI not working when using an URL ending with a slash #1805
Comments
|
Please run this command in your console and show us the result: You should have all these 6 bundles active and all from the same OH version. Your first log message (enhab.ui.internal.UIErrorPageServlet) is logged by MainUI so I understand that you start Basic UI from MainUI. |
|
Mine looks the same: I don't start Basic UI from Main UI, I'm just refreshing a basicUI page that's already open on this URL: http://raspberrypi2:8080/basicui/app/?sitemap=default If I restart with no pages open and refresh just that one page I still get that error. I've attached the full reboot trace with trace logging on the UI ( log:set TRACE org.openhab.ui). Nothing in there is jumping out at me, but it may give you some ideas. I also opened a browser on http://raspberrypi2:8080/basicui/app/ but that still gave similar errors as before, my interpretation is that it's falling back to the error page servlet for some sort of page not found error. It's not clear to me why it's not found, or where I'd look to see if there's something corrupt about the file, or perhaps something wrong with the paths. I'm assuming the fact the bundle is active would mean it was found and unpacked properly though. |
|
Like I mentioned in the forum, I get the same error on openHAB 3.4.1 release, meaning the BasicUI is now broken. |
You are apparently running 3.4.0 and not 3.4.1. |
I'm not sure. Main UI /about/ says:
This is the first time I'm seeing the error, so no. It was working fine until a few days ago. Before the error occurred, I was changing items, sitemap and py files, which were being uploaded with WinSCP "Keep remote directory up to date" using a very slow and error prone VPN connection. I probably restarted openhab before the error occurred too. |
|
I have no idea what happening but I am almost certain it has no link with any change done in BasicUI code. |
Why does it use path |
|
And tris log is done by code belonging to MsinUI. Maybe when MainUI tries to retrieve icons? Are you both behind a reverse proxy that rewrites URL? |
|
I'm not using any proxy or any complex configuration. Raspberry pi with openhab installed directly on it, connecting directly to that raspberry pi on port 8080 from the browser. The issue occurs across two different devices (phone and laptop) and two different browsers on each (Chrome and Safari), so pretty sure it's not client side. It seems to me that it's failing to find a file or files that it expects to find. I'm very willing to help debug that, but it's not clear to me where it would be looking to find those files. My best guess is that there's a package in the wrong location or a file permissions issue or something like that. In order to provide assistance with that, I'd need to know where the files that it's trying to return should be residing - I'm assuming it's /var/lib/openhab/xxxxx, but I'm not sure exactly where. Or perhaps they get unpacked into a temp directory on startup, or maybe they're memory resident. It seems unlikely they'd get unpacked again on every web request, so I'm sort of expecting to see them on the file system somewhere. I don't personally think an upgrade caused this issue - it happened when I rebooted (some changes to the physical burner on the diesel boiler meant I had it powered down). I hadn't upgraded any time recently, and any upgrade always triggers a restart of openhab even if not the whole machine. When I got the issue I did then run an upgrade, but the upgrade did not trigger the issue. It is plausible that I had upgraded months ago without restarting the whole machine, and that therefore some permissions or file location thing didn't take effect until the reboot. That seems to me the most likely problem - since it's clearly not finding the files to return, and yet the bundle appears to be present and active. |
|
On the question of URLs and why it's using particular paths, this is what my browser console is reporting: The page it is displaying below is: http://raspberrypi2:8080/basicui/app/ You can see the html is requesting, for example, material-icons.css and smarthome.js, which would be relative to the url - so http://raspberrypi2:8080/basicui/app/smarthome.js. I wonder whether what's going on is that it's failing to find the basicui index.html (if there is such a thing), and is instead returning the index.html from the standard ui. That, in turn is trying to load the icons etc that it expects, but because the url that the browser requested was http://raspberrypi2:8080/basicui/app/index.html, it's all failing, because the page actually returned was http://raspberrypi2:8080/app/index.html. Does that make sense? It's clearly not that url, because I tried retrieving that page directly. |
|
I'm not using a reverse proxy, just a VPN (WireGuard) to access remotely. |
|
Does it work if you use http://raspberrypi2:8080/basicui/app instead? I think the issue is reproducible using URLs like: http://raspberrypi2:8080/basicui/app/index.html Perhaps some redirect needs to be added to fix this. |
|
I solved the issue. I was using the following URL, which does not work: It does work when I use this URL, without trailing slash: If you go to MainUI, click Other apps, BasicUI, then the correct URL is used. I would say that is a bug. The existence or nonexistence of a trailing slash should not break an app. |
|
This also works to resolve my issue. However, the URL I use hasn't changed for a long time - so it must have worked in the past then stopped working. Either way, happier with it working. |
lolodomo
changed the title
lolodomo
changed the title
|
I am not sure it makes sense to end the URL with a slash while the URL can contain parameters (like sitemap). |
Fix openhab#1805 Signed-off-by: Laurent Garnier <[email protected]>
|
I get that. It's just weird that it used to work, with parameters. I'm pretty sure I never entered that URL directly, so at some point in time it put that slash on automatically. With parameters it used to look like: http://raspberrypi2:8080/basicui/app/?sitemap=default |
In what OH versions was this supposed to be working? I tried such URLs in some older OH 3 versions but for me it results in similar issues as with OH 4. Maybe it was only supported by the proxy config in openHABian? |
It is also reported to occur with OH 3.4.3 (openhab/openhab-core#3561) which does not have these changes. |
Fixes #1805. Signed-off-by: Laurent Garnier <[email protected]>
Refer this discussion on the community pages: https://community.openhab.org/t/basicui-not-loading-any-css-or-icons-after-reboot/145424
I'm running on a RaspberryPi with Debian and an apt install, currently on 4.0.0.M1.
My install was operating fine, after a reboot the basic UI wasn't delivering any CSS, Javascript or icons, and this is consistent across Safari and Chrome, and both on my laptop and on my phone (unlikely to be a cookie or cache issue). It is delivering the index page, but for all other pages there's a message in the log along the lines of:
Reviewing the javascript console I can see that for files such as manifest.json and the javascript files the actual content returned is the index.html (which is also what the error from the log above says that it's doing).
At that point I suspect I was on an earlier build, but I don't know what exact earlier build. I ran a full upgrade, bringing me to 4.0.0.M1, in the hopes of correcting the issue, but the problem continues to occur.
The iOS app is still rendering properly.
The icon bundle is installed and active, no bundles are reporting inactive. I'm assuming the icon bundle isn't the problem, as javascript and css also are not returned.
These lines from the debug log on startup were the only other things I found in the log that looked maybe relevant. They actually look OK to me, but it did fail to find an activate method - which may be because there isn't supposed to be one, or may be because something is broken.
I suspect a reinstall will fix the problem, but that wouldn't avoid other people getting the same problem. Are there more diagnostics I can usefully perform? I'm assuming the files themselves must be unpacked in a cache somewhere that I could look at to see if the files are potentially missing?
The text was updated successfully, but these errors were encountered: