Gatsby: ERR_SSL_PROTOCOL_ERROR when using `gatsby develop --https`

[Mrtenz]

Description

When using gatsby develop --https, I see a lot of ERR_SSL_PROTOCOL_ERROR errors in the console, for what seems to be socket.io related requests. I am using the (currently) latest version of Gatsby.

It happens about every 5 seconds, which makes it annoying to use the console to debug other things. The page seems to work fine, and HMR works without issues too, regardless of the errors.

Steps to reproduce

Go to this repo and follow the instructions: https://github.com/Mrtenz/gatsby-https-issue

Alternatively, run this in an existing Gatsby project:

1. Run gatsby develop --https
2. Open the page and check the console

Expected result

There shouldn't be any SSL errors.

Actual result

There are SSL errors.

Environment

  System:
    OS: Linux 5.8 Arch Linux
    CPU: (16) x64 AMD Ryzen 7 3800X 8-Core Processor
    Shell: 5.8 - /usr/bin/zsh
  Binaries:
    Node: 12.18.3 - /tmp/yarn--1602600057219-0.43846647488335666/node
    Yarn: 1.22.10 - /tmp/yarn--1602600057219-0.43846647488335666/yarn
    npm: 6.14.6 - ~/.nvm/versions/node/v12.18.3/bin/npm
  Languages:
    Python: 3.8.6 - /usr/bin/python
  Browsers:
    Firefox: 81.0.1
  npmPackages:
    gatsby: ^2.24.76 => 2.24.76
    gatsby-plugin-canonical-urls: ^2.3.13 => 2.3.13
    gatsby-plugin-create-client-paths: ^2.3.13 => 2.3.13
    gatsby-plugin-layout: ^1.3.13 => 1.3.13
    gatsby-plugin-manifest: ^2.4.34 => 2.4.34
    gatsby-plugin-offline: ^3.2.31 => 3.2.31
    gatsby-plugin-react-helmet-async: ^1.1.0 => 1.1.0
    gatsby-plugin-react-redux: ^1.1.0 => 1.1.0
    gatsby-plugin-robots-txt: ^1.5.3 => 1.5.3
    gatsby-plugin-s3: ^0.3.5 => 0.3.5
    gatsby-plugin-sitemap: ^2.4.16 => 2.4.16
    gatsby-plugin-styled-components: ^3.3.14 => 3.3.14
    gatsby-plugin-ts-config: ^1.1.0 => 1.1.0
    gatsby-plugin-typescript: ^2.4.21 => 2.4.21
    gatsby-plugin-typescript-checker: ^1.1.1 => 1.1.1
    gatsby-plugin-webpack-bundle-analyser-v2: ^1.1.13 => 1.1.13

[wardpeet]

I don't have that issue on windows. I see that it's arch Linux. Are there other platforms that have this issue, like ubuntu?

[Mrtenz]

I made a minimal reproduction repo where I can reproduce this issue. Would be great if someone with Ubuntu or other Linux distro could test this, as I do not have (easy) access to an Ubuntu machine.

https://github.com/Mrtenz/gatsby-https-issue

[Mrtenz]

I just tested it on Firefox, and I get a different error, CORS related:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://localhost:36443/socket.io/?EIO=3&transport=polling&t=NKhqkE-. (Reason: CORS request did not succeed).

Manually navigating to the Socket.io URL results in this error:

An error occurred during a connection to localhost:36443. SSL received a record that exceeded the maximum permissible length.

Error code: SSL_ERROR_RX_RECORD_TOO_LONG

[iDiegoNL]

I can confirm that this issue also appears when using Ubuntu.

[vrabe]

I access those URLs with curl, and curl returns

curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number

[valeeum]

Same issue here. Something to note is that on 2.24.78, the site is served on port 8000 but socket.io connection using another port. On 2.24.55, both site and socket.io connection is served over the same port and works as expected.

[tmttn]

This was broken in #27302. Looking at the related issue (#27294), the PR was trying to fix some mixed content errors. The description of this issue contains the following:

bug introduced from: #24335 (particularly a7f92af)

I think that the fix in #27302 was too short-sighted. Namely because there were a lot of changes in #24335 to ensure that the socket.io connection would go through the proxy instead of directly to the socket.io server.

We are now bumping into CORS issues because the server does not allow localhost:8000 as an origin. Going through a proxy as described in #24335 is a viable solution to this problem, but 0be31899305dd85ec7aaf206f6777d17933eaaa4 broke this again.

[scottalan]

Holy cow! ++ to tracking all that down.

I'm rolling back to [email protected] to confirm that what @valeeum stated earlier applies in our situation as well.

[tmttn]

Holy cow! ++ to tracking all that down.

I'm rolling back to [email protected] to confirm that what @valeeum stated earlier applies in our situation as well.

With pleasure! I investigated this in order to find a fix, but since I have no hands-on experience with the codebase yet, I wasn't sure how to tackle it. So I decided to document my findings instead. 😅

[wardpeet]

Thanks a lot for the information. I'll keep you posted and sorry for the inconveniences

[tmttn]

In the end... it did prove to be that easy. I spent way too much time on this. The thing that tripped me up hard is the following:

I changed the socket URL to ${window.location.protocol}//${window.location.hostname}:${window.location.port}, but I don't understand how the http-proxy (packages/gatsby/src/utils/develop-proxy.ts) correctly handles proxy-ing this URL to developstatusserver. As this was the previously configured port, I assume that the request should end up there. This baffles me because in packages/gatsby/src/commands/develop.ts, the targetPort of the proxy is configured with developPort and not with statusServerPort, meaning that the socket URL would end up on another server?

tl;dr: I sent the socket URL to the proxy again, but I don't understand how to proxy forwards the request to the correct port...

[github-actions[bot]]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 20 days since the last update here.
If we missed this issue or if you want to keep it open, please reply here.
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 💪💜

[tmttn]

Not stale, my PR just needs a review ;(