Selenium firefox driver forces https

Question

I have a functional app running in a docker on port 3000. I have selenium tests that works when I set my host to http://localhost:3000. I created a container to launch the selenium tests and it fails with the following error:

WebDriverError:Reachederrorpage:about:neterror?e=nssFailure2&u=https://app:3000/&c=UTF-8&f=regular&d=An error occurred during a connection to app:3000.

SSL received a record that exceeded the maximum permissible length.

Error code: <a id="errorCode" title="SSL_ERROR_RX_RECORD_TOO_LONG">SSL_ERROR_RX_RECORD_TOO_LONG</a>

Snippet of my docker-compose.yml

app:
    build:
        context: .
        dockerfile: Dockerfile.dev
    volumes:
        - ./:/usr/src/app/
    ports:
        - "3000:3000"
        - "3001:3001"
    networks:
        tests:

selenium-tester:
    build:
        context: .
        dockerfile: Dockerfile.selenium.tests
    volumes:
        - ./:/usr/src/app/
        - /dev/shm:/dev/shm
    depends_on:
        - app
    networks:
        tests:

I replaced the host by http://app:3000 but firefox seems to want to redirect this http to https (which is not working). And finally I build my driver like this:

const ffoptions = new firefox.Options()
  .headless()
  .setPreference('browser.urlbar.autoFill', 'false'); // test to disable auto https redirect… not working obviously
const driver = Builder()
      .setFirefoxOptions(ffoptions)
      .forBrowser('firefox')
      .build();

When manually contacting the http://app:3000 using curl inside the selenium-tester container it works as expected, I get my homepage.

I'm short on ideas now and even decomposing my problem to write this question didn't get me new ones

Answer 1

I had exactly the same problem - couldn't successfully make request on HTTP to app from Selenium-controlled browsers (Chrome or Firefox) in other Docker container on same network. cURL from that container though worked fine! Connect on HTTP, but something seemed to be trying to force HTTPS. Identical situation right down to the name of the container "app".

The answer is... it's the name of the container!

"app" is a top level domain on the HSTS preloaded list - that is, browsers will force access through HTTPS.

Fix is to use a container name that isn't on HSTS preloaded lists.

HSTS - more reading

Answer 2

As you mentioned manually contacting the http://app:3000 using curl inside the selenium-tester container it works as expected

This error message...

WebDriverError:Reachederrorpage:about:neterror?e=nssFailure2&u=https://app:3000/&c=UTF-8&f=regular&d=An error occurred during a connection to app:3000.
SSL received a record that exceeded the maximum permissible length.
Error code: <a id="errorCode" title="SSL_ERROR_RX_RECORD_TOO_LONG">SSL_ERROR_RX_RECORD_TOO_LONG</a>

...implies that SSL layer in curl or one of its dependencies seems broken.

@RussellFulton in this discussion mentioned:

This seems to be the result you see from Firefox when the server is not configured properly for SSL. Possibly Chrome would have just gave a generic ssl failed error.

This can happen when the browser sends a SSL handshake when the server is expecting an HTTP request. Server responds with a 400 code and an error message that is much bigger that the handshake message that the browser expects. Hence you see the message.

---

Reasons and Solution

• When the error prone code tries to redirect to HTTPS on port 80 (port 3000 in your case).
  • Solution: Removing the port 80 (port 3000 in your case) from the url, the redirect works.

HTTPS by default runs over port 443.

• This error also occurs when you have enabled the SSL module.

  • Solution: You have run a2enmod ssl.

    a2enmod ssl //or a2ensite default-ssl

• Provided a wrong IP in the ssl config.

  • Solution: Changed IP to what it should be.

• Remove the IP if not needed in the ssl config.

  • Solution: Change

    VirtualHost your.domain.com:443 //to VirtualHost default:443

• curl: (35) SSL received a record that exceeded the maximum permissible length. issue was discussed at length.

• As per Curl Support HTTPS proxy and SOCKS+HTTP(s) there was another attempt to get the HTTPS proxy support into Curl.

• This curl commit should have addressed your issue.