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

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:

Run gatsby develop --https
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

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 3
Comments: 16 (9 by maintainers)

Most upvoted comments

I’m experiencing these issues again but this time on the develop server so the localhost dev server never loads to begin with. The problem doesn’t exist when I reference “gatsby”: “4.14.1” in package.json but does when I specify “gatsby”: “^4.14.1”. Depending on the version of gatsby I install i get one of the following errors:

valeeum on Jul 20, 2022

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! 💪💜

github-actions[bot] on Nov 10, 2020

Holy cow! ++ to tracking all that down.

I’m rolling back to gatsby@2.24.55 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. 😅

tmttn on Oct 19, 2020

Not stale, my PR just needs a review 😭

tmttn on Nov 10, 2020

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.

tmttn on Oct 19, 2020