responsively-org/responsively-app · warning

Protocol not supported

Error message

Protocol not supported

What it means

isValidCliArgURL validates command-line URL arguments by parsing them with new URL() and checking the protocol against an allowlist of http:, https:, and file:. If the argument parses but uses any other scheme (ftp:, chrome:, mailto:, custom app schemes), the function logs 'Protocol not supported' with the offending protocol and returns false, rejecting the CLI argument.

Source

Thrown at desktop-app/src/main/util.ts:35

let isCliArgResult: boolean | undefined;

export function isValidCliArgURL(arg?: string): boolean {
  if (isCliArgResult !== undefined) {
    return isCliArgResult;
  }
  if (arg == null || arg === '') {
    isCliArgResult = false;
    return false;
  }
  try {
    const url = new URL(arg);
    if (url.protocol === 'http:' || url.protocol === 'https:' || url.protocol === 'file:') {
      isCliArgResult = true;
      return true;
    }
    // eslint-disable-next-line no-console
    console.warn('Protocol not supported', url.protocol);
  } catch (e) {
    // eslint-disable-next-line no-console
    console.warn('Not a valid URL', arg, e);
  }
  isCliArgResult = false;
  return false;
}

export const getPackageJson = () => {
  let appPath;
  if (process.env.NODE_ENV === 'production') appPath = app.getAppPath();
  else appPath = process.cwd();

  const pkgPath = path.join(appPath, 'package.json');
  if (fs.existsSync(pkgPath)) {
    const pkgContent = fs.readFileSync(pkgPath, 'utf-8');
    return JSON.parse(pkgContent);
  }

View on GitHub (pinned to e5623c5a70)

Solutions

1. Use an http/https/file URL when passing arguments on the command line
2. If other schemes must be supported, extend the allowlist check to include the needed protocols
3. Strip or normalize the scheme before validation if the intent is to treat the argument as a host/path
4. Check the console.warn output for the exact rejected protocol to confirm the scheme mismatch

Example fix

// before
myapp --open ftp://example.com/file.txt
// after
myapp --open https://example.com/file.txt

const SCHEMES = ['http:', 'https:', 'file:'];
function isSupportedCliUrl(arg: string): boolean {
  try {
    return SCHEMES.includes(new URL(arg).protocol);
  } catch {
    return false;
  }
}

function isSupportedProtocol(u: URL): u is URL & { protocol: 'http:' | 'https:' | 'file:' } {
  return u.protocol === 'http:' || u.protocol === 'https:' || u.protocol === 'file:';
}

When it happens

Trigger: Passing a CLI argument like ftp://host/file, myapp://deep/link, mailto:user@x.com, or data:text/html,... to the app binary; the URL parses successfully so the catch block is skipped and the protocol warn fires.

Common situations: Users passing deep links from OS protocol handlers, scripts passing ftp or ws URLs, protocol-handler registrations mapping custom schemes to the Electron binary.

Related errors

• Not a valid URL
• Invalid URL

AI-assisted analysis of responsively-org/responsively-app@e5623c5a70 (2026-08-31). Data as JSON: /api/errors/24a3b3e5bb1ae2b1. Report an issue: GitHub.