Codechecker fresh docker compose project does not serve.

[tracure1337]

I started a fresh project but it does not work at all.

I only want to try it out.

[prasilva98]

Hey,
ever got a solution to this?
thanks.

[paulosousadias]

Works on v6.24.4 and breaks calling not from localhost:8001 and using the IP from v6.24.5 and up

[tracure1337]

No solution yet unfortunately. Will use 6.24.4 for now.

[bruntib]

We'll investigate the issue. As a workaround 127.0.0.1 or localhost could be used in a local browser.

[paulosousadias]

Additional info. As I was making the docker for arm64 for the codechecker-web (issue #4461), when created the docker image, it will fetch the master branch. And I was able to access the web page from the IP of the machine. So looks ok as built from my Dockerfile (which is the same as your but tweaked for arm64).

Additional note. The dockerhub version, v6.24.5, v6.24.6 and v6.24.7 have the same issue.

[ChaKiG]

Any news on this ? I also had to rollback a few CodeChecker servers due to this

[MarkoSagadin]

I was also affected by this.

I upgraded to latest version (v6.25.0) and performed the automatic migration of the database files.

Although the server login worked last week, it stopped working today.

I had to downgrade back to 6.24.4 as suggested above, however I lost the ability to use the database files, since the automatic scripts can't "downgrade" them.

[Discookie]

My best guess as to what happens is that the browser somehow learned that there's some service supporting HTTP/2 on this same IP, and the browser tries to connect to CodeChecker using HTTP/2, which isn't supported. It's also possible that the browser does some other weird things on your machines, which makes the HTTP negotiation fail.
During the process of handling the failure, there's another bug introduced by bab3ece, which should be fixed with #4506. Once that's merged, you'll have a bit more information about the type of failure that happens during the request.

[tracure1337]

I tried with multiple browsers on different machines and I am not the only one reporting this.

[Falital]

This happens if you dont use https, because upgrade-insecure-requests is set. This option instructs the browser to "upgrade" all http:// URLs to https:// since https is not active the call fail. To fix this you can either generate dummy certs for your server.

openssl req -x509 -newkey rsa:4096 -sha256 -nodes -keyout key.pem -out cert.pem -days 365

Or you can remove 'upgrade-insecure-requests;' in RequestHandler class. I created patch that should fix this

server.py.patch

@Discookie you can intergrade this in #4506 or I can create a pr myself.

[Discookie]

@Falital Oh I didn't see your comment until now, thanks for noticing this! Those CSP headers indeed shouldn't apply if HTTPS is not configured on the server. That fixes the root cause of the original issue as well.