Web-UI page empty on 0.101.0

Hello,

I just updated to latest version of the add-on (0.101.0) together with latest versions of home-assistant (0.114.1) and supervisor (234). I am running Home Assistant Supervised in a raspberrypi4 running raspbian. Everything was working properly before updating. However now I can not access the web-ui of the add-on and there seems to be nothing in the logs (with verbose: true):

08-15 15:37:39 INFO Starting server on port 8099
08-15 15:37:39 INFO Server started
08-15 15:37:39 INFO Syncing Snapshots

However there are some errors in the Supervisor log (but I don’t know if they are related):

20-08-15 13:37:34 ERROR (MainThread) [supervisor.api.ingress] Ingress error: 
20-08-15 13:37:34 ERROR (MainThread) [supervisor.api.ingress] Ingress error: 
20-08-15 13:37:35 INFO (SyncWorker_5) [supervisor.docker.interface] Clean addon_cebe7a76_hassio_google_drive_backup application
20-08-15 13:37:37 INFO (SyncWorker_2) [supervisor.docker.addon] Start Docker add-on sabeechen/hassio-google-drive-backup-armv7 with version 3.12
20-08-15 13:37:39 INFO (MainThread) [supervisor.api.security] /homeassistant/info access from cebe7a76_hassio_google_drive_backup
20-08-15 13:37:39 INFO (MainThread) [supervisor.api.security] /supervisor/info access from cebe7a76_hassio_google_drive_backup
20-08-15 13:37:39 INFO (MainThread) [supervisor.api.security] /snapshots access from cebe7a76_hassio_google_drive_backup
20-08-15 13:37:39 INFO (MainThread) [supervisor.api.security] /snapshots/7876c97e/info access from cebe7a76_hassio_google_drive_backup
20-08-15 13:37:39 INFO (MainThread) [supervisor.api.security] /snapshots/cc78f0f7/info access from cebe7a76_hassio_google_drive_backup
20-08-15 13:37:39 INFO (MainThread) [supervisor.api.security] /snapshots/24a61829/info access from cebe7a76_hassio_google_drive_backup
20-08-15 13:37:39 INFO (MainThread) [supervisor.api.security] /snapshots/4a31f353/info access from cebe7a76_hassio_google_drive_backup
20-08-15 13:37:39 INFO (MainThread) [supervisor.api.security] /snapshots/bca5966e/info access from cebe7a76_hassio_google_drive_backup
```

[sabeechen]

I’ve made some progress, though I don’t have things fully figured out yet. This has something to do with websockets and connection upgrades getting passed through the proxies.

Special thanks to @jrhbcn and @mgriffin13, I was able to set up a host with all the necessary proxy routing to reproduce the problem. Finally!

The web-ui hangs on this minimal Nginx config:

server {
    listen 80;

    location / {
        proxy_set_header Host $host;
        proxy_redirect http:// https://;
        proxy_http_version 1.1;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_pass http://192.168.0.100:8123;
    }
}

But it works properly with this config:

  map $http_upgrade $connection_upgrade {
      default upgrade;
      ''      close;
  }

  server {
    listen 80;

    location / {
        proxy_set_header Host $host;
        proxy_redirect http:// https://;
        proxy_http_version 1.1;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_pass http://192.168.0.100:8123;
    }
}

The critical difference is the line proxy_set_header Connection $connection_upgrade; and the map defined up top that defines $connection_upgrade. I was able to find some Nginx documentation that describes this, but I’m still not sure what I might be doing wrong with the addon’s web server. This problem only started happening when I switched the addon’s webserver to serving through the AioHttp server library, so clearly that is related.

Other addons seem to render fine without the change above, and moreover the web-ui also loads fine with the “broken” config above if I proxy it directly to the addon’s webserver (eg port 1627). This issue only comes up when requests get routed through: Nginx proxy -> Supervisor ingress proxy -> Addon webserver

I’ll continue to try to figure this out, but I’m digging through a domain of knowledge I know nothing about. If someone understands what this Connection header does or why it might be causing problems, please chime in and help.

For the time being adding the map and proxy_set_header Connection $connection_upgrade; line seems to be a fix. For my config I copied it from this documentation on proxying home assistant.

[sabeechen]

@Appyx thansk for posting that, that gives me more to work with. In my experience, the supervisor’s proxy returns a 502 error for basically any error the addon’s webserver returns. Its good to know something is getting through. I’d guess the delay in loading the body is just your browser attempting to load all the stylesheets and javascript resources before it attempts to actually render the page.

• /static/css/colpick.css is just one of the addon’s many stylesheets (used for the settings color-picker), it isn’t served any differently than any of the other static resources fromthe addon.
• /getstatus is what the addon calls periodically to refresh the web-UI while you’re watching it. It should request once every 5 seconds or so when things are working right.

Its hard to guess why some requests might get through and others would fail, all the endpoints for the addon are served in more-or-less the same way. It kind of sounds like the supervisor is getting hung up randomly, so parts of the web-ui loads paritally or not at all, which is why you’d see things styled incorrectly. Since many people have reported the web-ui working when exposed directly on a port, I’m still inclined to think this is a problem with the supervisor.

Come to think of it, I’ve been having quite a few problems with the latest supervisor version. Getting kind of fed up with the supervisor, actually. But maybe its something I’m doing.

@Appyx Do you see anything in the supervisor logs when the UI completes “partially” loading (eg at Supervisor > System)? The original user who posted saw a mostly blank error message [supervisor.api.ingress] Ingress error: but maybe something helpful gets printed out when you let it try to complete?

Some extra context for those who might be curious: The supervisor handles “ingress” (embedded addons like this one) by proxying requests from your browser to the web server’s addon. So for example this addon exposes a web server (inside a docker container), and the supervisor makes it available by loading the addon in an iframe. This is how all embedded addons work.