Proxy option leads to uncaught exception if passed without protocol

[MoritzKn]

Reproduce by running:

http-server --proxy google.com

You will get an error link this:

/Users/moritzkneilmann/.config/yarn/global/node_modules/requires-port/index.js:13
  protocol = protocol.split(':')[0];
                      ^

TypeError: Cannot read property 'split' of null
    at required (/Users/moritzkneilmann/.config/yarn/global/node_modules/requires-port/index.js:13:23)
    at Object.common.setupOutgoing (/Users/moritzkneilmann/.config/yarn/global/node_modules/http-proxy/lib/http-proxy/common.js:101:7)
    at Array.stream (/Users/moritzkneilmann/.config/yarn/global/node_modules/http-proxy/lib/http-proxy/passes/web-incoming.js:127:14)
    at ProxyServer.<anonymous> (/Users/moritzkneilmann/.config/yarn/global/node_modules/http-proxy/lib/http-proxy/index.js:81:21)
    at Array.<anonymous> (/Users/moritzkneilmann/.config/yarn/global/node_modules/http-server/lib/http-server.js:111:13)
    at dispatch (/Users/moritzkneilmann/.config/yarn/global/node_modules/union/lib/routing-stream.js:119:21)
    at Object.onceWrapper (events.js:273:13)
    at module.exports.emit (events.js:182:13)
    at /Users/moritzkneilmann/.config/yarn/global/node_modules/union/lib/routing-stream.js:114:23
    at Object.exports.(anonymous function) (/Users/moritzkneilmann/.config/yarn/global/node_modules/ecstatic/lib/ecstatic/status-handlers.js:37:5)

This is no issue if --proxy https://google.com is used.

PS: thanks for this package; it's an essential tool for testing for me 👍

[BigBlueHat]

google.com would be a file name (from a command line perspective), so there's nothing to proxy. Certainly the error message could be more helpful here.

Mind tossing a patch for this? Probably an error message about --proxy needing a URL containing a protocol/scheme.

[MoritzKn]

It could be a file, yes. But since it's immediately behind the flag it's used as the proxy. The URL is then later passed but since the protocol is not defined in the string it's undefined in the resulting object. The code then tries to access it – thats where it breaks. I debugged the code. I may submit a patch if I find time.

[BigBlueHat]

Yeah. Without a protocol scheme it's not a URL, so google.com isn't a valid absolute URL because it lacks a scheme.

Should be a simple fix, and thanks for taking a look!

[MoritzKn]

Well, it still gets parsed by URL.parse successfully. In the result however it indeed considers it to be a relative URL:

Url {
  protocol: 'http',
  slashes: null,
  auth: null,
  host: null,
  port: null,
  hostname: null,
  hash: null,
  search: null,
  query: null,
  pathname: 'example.com',
  path: 'example.com',
  href: 'example.com' }

I think it could also be possible to check for that and fallback to http for developer ergonomics. I mean I'd kinda expect http to be implicit on a http-server. After all curl example.com works too.

However if you would ever want to proxy through a linux socket for some reason, that would cause a conflict.

[BigBlueHat]

Actually, Node.js doesn't default the protocol to http (afaict):

const url = require('url');
console.log(url.parse('google.com'));

It correctly sets it as the pathname, path, and href values of the Url object--because there's not a default protocol.

Url {
  protocol: null,
  slashes: null,
  auth: null,
  host: null,
  port: null,
  hostname: null,
  hash: null,
  search: null,
  query: null,
  pathname: 'google.com',
  path: 'google.com',
  href: 'google.com' }

I'm 👎 on setting a default protocol for the proxy as I think it introduces a lack of clarity and invites errors. Requiring the protocol scheme seems best. Thanks.

[MoritzKn]

I know that node.js doesn't default to http, that makes sense for me, I was talking about doing it in the code of this module.
Anyway I'm fine with trowing an error too.

[BigBlueHat]

I'd prefer the error. At the very least it's unclear what default would be expected: http vs. https.

👍 to better error reporting/handling though!

[cliffpyles]

Looks like this one wasn't resolved. Is anyone working on it? Want me to take a shot at it?

[atljoseph]

Please take a shot at it. All that needs to be done (I think, at least ...) is a pretty error which kicks back the passed in url value which is triggering the discussed error. Then, the developer will be armed with 10X more knowledge about the issue than previously, and will be able to correct their environmental configuration mistake. I triggered this by using a host of 8080 when assuming a specific env var only needed the port instead of the host and port, like this: http://localhost:8080. It should check for the presence of all supported protocols, and add a suggestion to the error, however it maybe should not produce an error WRT protocol ... just in case someone chooses to use a weird protocol.

[dilanhag]

What is the solution for this? I tried everything. For me it's working fine in windows PC. But not in mac. It was working fine earlier. Now it gives the error TypeError: Cannot read property 'split' of null. required-port

[sudoman281]

If you read the error, you see it's trying to split the protocol variable. So I went thru the documentation and there is an example of the correct usage of the parameter:
-P http://someurl.com
So the fix is to add https:// or http:// to the beginning of your URL address and everything will work. :)

[thornjad]

That's absolutely correct, add the protocol to the URL and it should work correctly. As discussed above, http-server can't safely assume a path without a protocol is a URL, and neither can Node. The resolution to this issue is to improve the error message when this happens, probably including a friendly tip to add the protocol if the failed URI didn't have one.