There seems to be inconsistent handling between the regular expression check used to validate the https protocol and string comparison checks against 'https:' in a few different locations in the code.

The regular expression defined here
https://github.com/http-party/node-http-proxy/blob/master/lib/http-proxy/common.js#L7
does not check for the trailing colon on the protocol.

However, the check in web-incoming here:
https://github.com/http-party/node-http-proxy/blob/master/lib/http-proxy/passes/web-incoming.js#L111-L113
and here:
https://github.com/http-party/node-http-proxy/blob/master/lib/http-proxy/passes/web-incoming.js#L126-L128
are requiring the trailing colon prior to calling common.setupOutgoing

If a user passes a target object that includes https without the colon, setupOutgoing will set protocol to 443 here: https://github.com/http-party/node-http-proxy/blob/master/lib/http-proxy/common.js#L35 while returning false in the ternary === 'https:'

I have made a fork with a PR which moves the two checks in web-incoming to follow the same regex check used in ws-incoming for this logic (here: https://github.com/http-party/node-http-proxy/blob/master/lib/http-proxy/common.js#L35)

I was investigating adding some tests to verify this behavior in the stream method but could use some eyes from the maintainers in that regard