--anyorigin means 'accept any origin' and cannot be combined

Error message

--anyorigin means 'accept any origin' and cannot be combined with --sameorigin or --origin, which restrict it

What it means

validateAnyOrigin rejects --anyorigin combined with --sameorigin or --origin. --anyorigin means 'accept any origin', while the other flags restrict origins — the flags are contradictory and silently preferring one would hide operator confusion.

Source

Thrown at config.go:163

}

// validateBinaryPassStderr checks that --binary and --passstderr aren't both
// set. Tagging binary chunks as JSON isn't implemented (--passstderr always
// reads line by line), so combining the two would silently discard --binary
// instead of behaving as either flag alone.
func validateBinaryPassStderr(binary, passStderr bool) error {
	if binary && passStderr {
		return fmt.Errorf("please only specify one of --binary and --passstderr")
	}
	return nil
}

// validateAnyOrigin checks that --anyorigin is not combined with an actual
// origin policy. The flags say opposite things, and silently preferring one
// would hide operator confusion.
func validateAnyOrigin(anyOrigin, sameOrigin bool, allowOrigins []string) error {
	if anyOrigin && (sameOrigin || allowOrigins != nil) {
		return fmt.Errorf("--anyorigin means 'accept any origin' and cannot be combined with --sameorigin or --origin, which restrict it")
	}
	return nil
}

// validateMaxFrameSize rejects negative --maxframesize values. The read
// limit is only applied for positive values, so a negative value silently
// meant "unlimited" — the one value an operator can pass that quietly
// removes the DoS protection the flag exists for (issue #472).
func validateMaxFrameSize(maxFrameSize int64) error {
	if maxFrameSize < 0 {
		return fmt.Errorf("--maxframesize must not be negative; use 0 for unlimited")
	}
	return nil
}

// buildParentEnv constructs the filtered parent environment variable list.
func buildParentEnv(passenv string) []string {
	env := make([]string, 0)

View on GitHub (pinned to 7a8683dc7f)

Solutions

Keep only --anyorigin if you truly want to accept all origins (insecure; avoid in production)
Remove --anyorigin and keep --sameorigin or the explicit --origin list to restrict origins
Audit wrapper scripts/env so origin policy comes from a single source

Example fix

// before
websocketd --anyorigin --origin=http://example.com --port=8080 ./script.sh
// after
websocketd --origin=http://example.com --port=8080 ./script.sh

Defensive patterns

Strategy: validation

Validate before calling

const originFlags = [args.includes('--anyorigin'), args.includes('--sameorigin'), args.filter(a=>a.startsWith('--origin=')).length > 0];
if (originFlags.filter(Boolean).length > 1) throw new Error('use only one origin policy flag');

Try / catch

try { startServer(args) } catch (e) { if (/--anyorigin.*cannot be combined/.test(e)) console.error('choose --anyorigin OR --sameorigin/--origin, not both'); throw e; }

Prevention

Define the origin policy in exactly one place (one flag set, one config source)
Prefer explicit --origin lists in production; reserve --anyorigin for local dev

When it happens

Trigger: Running websocketd with --anyorigin together with --sameorigin, or with one or more --origin=URL values (allowOrigins non-nil).

Common situations: Layering origin flags from multiple config sources (shell wrapper plus CLI); copying an example command line that already had --origin and appending --anyorigin to 'fix' CORS errors.

Related errors

AI-assisted analysis of joewalnes/websocketd@7a8683dc7f (2026-09-03). Data as JSON: /api/errors/05ba89ac3a4c5696. Report an issue: GitHub.