Example minimal config for https

[eddiesholl]

Documentation Is:

• Missing
• Needed
• Confusing
• Not Sure?

Please Explain in Detail...

Not sure if this fits better under your doc issue tag of under help/support, either way any help much appreciated here!

I'm trying to upgrade my config from a much older version of webpack-serve, and I'm struggling to find a minimal config for the https setting object. I have managed to resolve a few other problems, but am currently stuck with my browser complaining about opening an insecure WebSocket connection.

Looking at my previous config, I was setting hot.https = true. I guess I'm looking for the simple equivalent settings to get parity with this old setting. I've tried setting https = {}, and followed the guidance in the node docs that are linked as well, but every combination I have tried so far puts the dev server in a state where it refuses to serve other content (inside my docker container setup).

Your Proposal for Changes

An https example that offers parity with the old hot.https = true

[shellscape]

Welcome. We can certainly add one to the /recipes. Can you paste what you came up with when setting the https option to an object?

[eddiesholl]

Don't have anything that works yet 😅 I'm also looking for some help to get it working.

All the combinations of settings passed to the https object so far have stopped the regular file serving activities to be broken. Here's roughly what I have added to my package.json:

  "serve": {
    "port": "5051",
    "host": "0.0.0.0",
    "https": {},
    "client": {
      "address": "dev.foo.com/app/__webpack_hmr",
      "silent": false,
      "retry": true
    },
    "hmr": true,
    "static": ["public/static-content", "public/dist"],
    "log": {
      "level": "debug"
    }
  }

As soon as anything is getting passed to https, my container seems to stop responding on 5051, while it's fine without it.

I had a very similar set of options working in this docker setup with 0.3.0 of webpack-serve, with https = true

[shellscape]

well my advice on this would be to get this working outside of a container first. containers can cause complications when trying to debug something like this.

[eddiesholl]

Thanks, good suggestion. I think where I've got to is that our previous working config was relying on the ability to split the hot client config so that client requests use https, but that https is not used for the config of the web server itself. This works nicely with our dev tooling, where we have a standard nginx image that dispatches requests to the relevant container. So we want https requests from the client, but dev servers not serving via https.

I'm going to push further to see if its possible to recreate this split between the client and server https config.

UPDATE: Yes, it does look like the new code base is much more in alignment between the server and client paths, and the setting secure is inherited directly from whether https is set. I can't see any way to have parity with the previous possible setup, with a vanilla http server, and a client that makes https requests.

This is a big pain given the other tooling I am trying to make this work with.

Would you consider any enhancement to offer a similar level of flexibility, for example the ability to provide seperate server and client config?

[pappasam]

@eddiesholl have you found any workarounds for this yet? I'm running into your exact issue (nginx, reverse proxying for local development, frustration ensues with webpack-plugin-serve)

[pappasam]

@shellscape any idea how we should proceed here? I think this is a fundamental design question because the client config and the server config cannot currently be separated without a hard fork of this codebase (afaik).

In order to use a reverse proxy to route https traffic to http traffic, we should provide a mechanism to request https but serve http.

If we don't want to support this use-case and don't intend to support it, then it'd be nice to have a written record here and we can close the issue.

[shellscape]

I'm open to changes, but the call for this feature has been minimal as to call it "edge." It's not something that I'll be working on for the project, and not a scenario that I've had need of, so I'm not familiar with what would be necessary to make it happen. I won't be working on the feature, but the community is welcome to step up. If the changes are dramatic, a fork might be necessary.