listening as both https and http server simultaneously

Hi,

I'm moving a project over from browserify to webpack and hit a snag this afternoon. For arcane reasons (involving chrome and atom-shell/chromium behaviors) I need both https and http instances of local dev/testing web servers.

webpack-dev-server is awesome, but I didn't find any directly supported way to instantiate on two ports at the same time.

Here's what I ended up doing (full code context, farther down below)...

webpack_dev_server.listen(8004);
http.createServer(webpack_dev_server.app).listen (8005);

I'd like to ask whether this is a reasonable solution, or whether there's a better thing I should be doing, or alternatively whether a pull request to implement simultaneous https/http at the API level would be welcome.

Below, the full gulpfile.js chunk ...

var webpack = require ("webpack");
var WebpackDevServer = require ("webpack-dev-server");
var webpackConfig = require ("./webpack.config.js");
var http = require ('http');

gulp.task ("webpack-dev-server", function (callback) {
    // modify some webpack config options
    var myConfig = Object.create (webpackConfig);
    myConfig.devtool = "#source-map";
    myConfig.debug = true;

    // Start a webpack-dev-server
    var wds = new WebpackDevServer (webpack(myConfig), {
    https: true,
        publicPath: "/web",    // +   myConfig.output.publicPath,
        stats: {
            colors: true
        }
    });
  wds.listen(8004);
  http.createServer(wds.app).listen (8005);
});

Thank you.

Glad you found a solution, but I think the use case is too rar to add options for this to the webpack-dev-server. Even without accessing internals you could start a proxy server.

I would like to see this actually. For the command line especially.

Does this also work with websockets?
I'm constantly getting http 404 for http://localhost:3001/sockjs-node/info?t=<...> when i use http.createServer(wds.app).listen(...).

This is actually not so rare situation 👍 I need also both http and https

Redirect from http to https also would be ok

bump. i always need both environments.
is this possible yet?

@sokra

@sokra Looks like this is not rare situation 😃

This is really not rare situation

I would also need both!

Yes please.

We need this!

I need this as well. Bump!

another +1 for this..

still need it

I need it.

PR welcome, we can start 2 servers

Need this too

I consider this a hack, so i still think a proper webpack property to allow redirect is needed, but here is a solution only using webpack and without having to spin up another local server frontend by nginx.

Basic idea: spin up 2 webpack dev servers, 1 listening on http one on https. Have the one listening on http implement a proxy to redirect to https.

// package.json

"server": "webpack serve --config webpack.config.js --env https=false & webpack serve --config webpack.config.js --env https=true",

// webpack.config.js

module.exports = (env) => {
	return {
		....
		devServer: {
			https: env && env.https === "true",
			...
			port: env && env.https === "true" ? 443 : 80,
			...
			proxy: !env || env.https === "false" ? {
				"/**": {
					target: "https://localhost",
					secure: false, // allows the https server to not have a proper certificate
				}
			} : {}
		},
		...
	};

}

Why you need HTTPS on dev env? Due http2/http3 support?

I am guessing there are multiple use cases, but we need it to communicated with the auth service which does not do CORS with non https services.

Why not use HTTPs and self signed certificate?

that's what we do

I also need to serve both http and https, any progress on this thread ?

The key changes:

Configure both HTTPS and HTTP servers explicitly.
Use the same app instance from WebpackDevServer to serve both protocols

Here's the edited code for gulp task

var webpack = require("webpack");
var WebpackDevServer = require("webpack-dev-server");
var webpackConfig = require("./webpack.config.js");
var http = require('http');
var https = require('https');
var fs = require('fs');
var gulp = require('gulp');

// Certificate files for HTTPS (use your own certificates)
var httpsOptions = {
key: fs.readFileSync('path/to/your/server.key'), // Replace with your key file
cert: fs.readFileSync('path/to/your/server.crt') // Replace with your certificate file
};

gulp.task("webpack-dev-server", function (callback) {
// Modify some Webpack config options
var myConfig = Object.create(webpackConfig);
myConfig.devtool = "#source-map";

// Start the WebpackDevServer for HTTPS
var wds = new WebpackDevServer(webpack(myConfig), {
    https: httpsOptions,
    publicPath: "/web", // Modify based on your setup
    stats: { colors: true },
    hot: true, // Enable Hot Module Replacement (optional)
    historyApiFallback: true // Enable single-page app fallback (optional)
});

// Listen on HTTPS
wds.listen(8004, "localhost", function (err) {
    if (err) throw err;
    console.log("WebpackDevServer (HTTPS) is running on https://localhost:8004");
});

// Create an HTTP server using the same WebpackDevServer app
http.createServer(wds.app).listen(8005, "localhost", function (err) {
    if (err) throw err;
    console.log("HTTP server is running on http://localhost:8005");
});

callback();

});

I found a workaround.

Set your dev server to https and configure a cert/key, also set the port to 3001. You can use mkCert to set these up.

Then set up the additional proxy:

import * as net from "net";
import * as tls from "tls";

function tcpConnection(conn: net.Socket) {
  conn.on('error', (err) => {
    console.error('Connection error:', err);
    conn.destroy();
  });
  conn.once('data', function (buf) {
    const isSSL = (buf[0] === 22);
    let proxy: net.Socket;
    const address = {host: '127.0.0.1', port: 3001}
    if(isSSL) {
      proxy = net.connect(address, () => {
        proxy.write(buf);
        conn.pipe(proxy).pipe(conn);
      });
    } else {
      proxy = tls.connect({
        ...address,
        // configure your CA cert that matches the cert/key from your dev server.
        //ca: fs.readFileSync("your-rootCA.pem")
      }, () => {
        proxy.write(buf);
        conn.pipe(proxy).pipe(conn);
      });
    }
    // Handle proxy errors
    proxy.on('error', (err) => {
      console.error('TLS proxy error:', err);
      proxy.destroy();
      conn.destroy();
    });
  });
}
net.createServer(tcpConnection).listen(3000);

The proxy will proxy un-encrypted traffic to the https dev server, and it will simply forward ssl traffic without checking SSL traffic.

Hey I am Interested in contributing this issue, How to get started ?

This should be clearly default behavior in case https devServer is used - which is requirement for e.g. secure sameSite cookies.

Would be good to see this realized after 10 years...

@MerzDaniel

@MerzDaniel Tehnically it is possible to wrap dev-server into plugin and do it, we have public API to start dev server, so you can have multiple instance of this plugin with different configuration, anyway it is on our roadmap

Navigation Menu

Repository navigation

listening as both https and http server simultaneously #126

12 remaining items

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

listening as both https and http server simultaneously #126

Description

Activity

sokra commented on Mar 25, 2015

tommedema commented on Apr 14, 2016

mzedeler commented on May 18, 2016

Jokero commented on Aug 16, 2017

Jokero commented on Aug 19, 2017

kitsunekyo commented on Mar 15, 2018

Jokero commented on Jul 31, 2018

jasonjiflyer commented on Aug 23, 2018

ehausen commented on Aug 30, 2018

michaelhartmayer commented on Jan 3, 2019

jayarjo commented on Aug 24, 2019

everscending commented on Sep 4, 2019

anandchakru commented on Nov 20, 2019

12 remaining items

sandorvasas commented on Feb 5, 2022

ruojianll commented on Apr 18, 2022

alexander-akait commented on Apr 18, 2022

flavianh commented on Jun 2, 2022

pedrettin commented on Jun 15, 2022

alexander-akait commented on Jun 15, 2022

pedrettin commented on Jun 15, 2022

alexander-akait commented on Jun 15, 2022

pedrettin commented on Jun 15, 2022

hieuzeta commented on Sep 19, 2023

SachinKharote commented on Dec 6, 2024

whazor commented on Dec 11, 2024

Anubhab2003 commented on Jan 3, 2025

MerzDaniel commented on Oct 13, 2025

alexander-akait commented on Oct 20, 2025

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions