bug(dev-webserver): Allow HTTPS from Startup.cs

[MarkPieszak]

Fixes #271
If someone uses https to spin up Kestrel, Webpack-dev-server is static & set to http. Added option to WebDevMiddlewareOptions to UseHttps to enable HMR when they're using/testing https.

[SteveSandersonMS]

Unfortunately it's not this simple. Apart from not compiling (can't assign to WebpackDevMiddlewareScheme; it's a const), this doesn't make the Webpack dev middleware listen for HMR requests on an https endpoint, which is what's really needed.

There's no straightforward way to have the Webpack dev middleware expose an HTTPS endpoint, because it would need a cert for localhost or whatever hostname you use when browsing to your dev machine's webserver.

Ideally we'd bypass this problem altogether by reverse-proxying the HMR requests from ASP.NET (independently of whether you connect to it via HTTP or HTTPS) into Node. I'll look into this.

[MarkPieszak]

I think you're right, for some reason it worked for me (but then again I might already have a spoof-cert setup for my localhost, didn't even think about that).

[gerardog]

IMO, if changes on Kestrel do not materialize, It may be easier to just let the developer deal with the self-certificate instalation. A minimal documentation would be a good starting point. A dev who already has Kestrel on HTTPS should have already worked out how to make the self-cert and so.

[halter73]

@gerardog What are the changes you would like from Kestrel?

[gerardog]

Sorry If I expressed myself poorly. What I understood is that this PR is an intent to fix #271 by making webpack-dev-server run on https. That would be fine by me even if I have to fight a little bit to configure the certificates.

Instead, #271 was fixed with another approach: a reverse-proxy. It is probably a better solution but it did not work and was rolled back because Kestrel throws "EPIPE broken pipe" and "ECANCELED operation canceled". That issue is scheduled for kestrel 1.1.0 milestone.

So, I was wondering if we could support webpack-dev-server on https in the meantime. Just my opinion.

[SteveSandersonMS]

@halter73 What we need to fix #271 is for Kestrel not to throw the ObjectDisposedException, which @CesarBS has already said will be fixed in 1.1.0.

The EPIPE/ECANCELED warnings will be irritating to people, since they will happen on every page reload in development mode, but from the conversation at aspnet/KestrelHttpServer#1103, it sounds like people will just have to live with them. (Note that the client-side code is part of Webpack, so we can't make it send any notification to the server that it's going to disconnect).

@gerardog Until 1.1.0 ships, you could use this technique to bypass the problem. It's not ideal but is the best I can suggest in the short term.

[gerardog]

Thanks Steve. It works.

There is even a easier way to allow mixed content in Chrome: In the address bar at the right end should be a 'shield' icon, you can click on that to run insecure content.