fix: unable to remotely connect to chrome#334
Conversation
Chrome requires the "host" header to be set to either an ip address or "localhost", otherwise it will not accept the connection
|
Hi Malte, yeah, I think this is related to #327, at least I was unable to get a Chrome connection without the header, and without setting it to "localhost" or 127.0.0.1. So I'm running the docker container using: With the remote-debugging-address still set to 0.0.0.0, but without the header no luck in connecting. And no, I do not need to use socat in this case, just the container as it is in the above command. |
|
🤔 But this is specifically what @MaeIsBad said in #327 wouldn't work anymore with recent Chromium. Don't get me wrong, I'm not opposed to the change you suggest at all, but I'd like to have a reasonable plan forward for remote chrome users, ideally incl. documentation. What chromium version do you get from |
|
Regarding your questions:
You are right that the network is a bridged network, that's the default podman creates on Mac 😄. I've tried to create a non-bridged network, but so far I've failed with that, but I'll try to test it later using an acutal network connection to my homelab server, maybe that will help finding out if it is working |
|
So reading through the Chrome issue tracker that is linked from #327, it seems that the version of Chrome I'm running now is older and still has the |
Chrome requires the "host" header to be set to either an ip address or "localhost", otherwise it will not accept the connection.
I've fixed it by requesting a "localhost" host, and then manually patching the websocket address in the reply from Chrome. The use case here would be a docker container running with Zenika/alpine-chrome, and my application in another docker container, with a shared network. Otherwise this might work with fixed IP's as well.