caddyserver/caddy · error

making request: %v

Error message

making request: %v

What it means

Returned when http.NewRequest rejects the request line assembled from the origin plus the URI in AdminAPIRequest. Because the origin is normalized ('http://127.0.0.1' for unix/fd, or the parsed host:port otherwise), failure almost always means the URI passed by the calling CLI command is malformed (spaces, control characters, or an invalid method string).

Source

Thrown at cmd/commandfuncs.go:799

		origin = "http://127.0.0.1" // bogus host is a hack so that http.NewRequest() is happy

		// the unix address at this point might still contain the optional
		// unix socket permissions, which are part of the address/host.
		// those need to be removed first, as they aren't part of the
		// resulting unix file path
		addr, _, err := internal.SplitUnixSocketPermissionsBits(parsedAddr.Host)
		if err != nil {
			return nil, err
		}
		parsedAddr.Host = addr
	} else if parsedAddr.IsFdNetwork() {
		origin = "http://127.0.0.1"
	}

	// form the request
	req, err := http.NewRequest(method, origin+uri, body)
	if err != nil {
		return nil, fmt.Errorf("making request: %v", err)
	}
	if parsedAddr.IsUnixNetwork() || parsedAddr.IsFdNetwork() {
		// We used to conform to RFC 2616 Section 14.26 which requires
		// an empty host header when there is no host, as is the case
		// with unix sockets and socket fds. However, Go required a
		// Host value so we used a hack of a space character as the host
		// (it would see the Host was non-empty, then trim the space later).
		// As of Go 1.20.6 (July 2023), this hack no longer works. See:
		// https://github.com/golang/go/issues/60374
		// See also the discussion here:
		// https://github.com/golang/go/issues/61431
		//
		// After that, we now require a Host value of either 127.0.0.1
		// or ::1 if one is set. Above I choose to use 127.0.0.1. Even
		// though the value should be completely irrelevant (it could be
		// "srldkjfsd"), if for some reason the Host *is* used, at least
		// we can have some reasonable assurance it will stay on the local
		// machine and that browsers, if they ever allow access to unix

View on GitHub (pinned to 50e54ee279)

Solutions

1. URL-encode path and query segments before passing them as the uri argument
2. Use a standard HTTP method string (GET, POST, DELETE)
3. If you see this as a Caddy user (not a plugin author), report it — a built-in command constructed an invalid request

Example fix

// before
resp, err := cmd.AdminAPIRequest(addr, "GET", "/config/"+strings.ReplaceAll(path, " ", " "), nil, nil)

// after
resp, err := cmd.AdminAPIRequest(addr, "GET", "/config/"+url.PathEscape(path), nil, nil)

// Encode dynamic path/query segments before building the URI for AdminAPIRequest:
uri := "/config/" + url.PathEscape(userPath)

err := apiCall(); if err != nil && strings.HasPrefix(err.Error(), "making request:") { /* fix uri/method and retry once */ }

When it happens

Trigger: A CLI command builds a URI containing unescaped characters or the method string is not a valid HTTP token. Rarely triggered by user input directly; usually a bug in a custom command or plugin invoking AdminAPIRequest with a bad uri/method.

Common situations: Third-party Caddy CLI plugins calling AdminAPIRequest with a URI that contains spaces or non-ASCII, or an empty method.

Related errors

• no admin server
• no traversable path
• path missing
• reading confirmation bytes from stdin: %v
• writing confirmation bytes to %s: %v

AI-assisted analysis of caddyserver/caddy@50e54ee279 (2026-08-15). Data as JSON: /api/errors/969ff03d1d575ed1. Report an issue: GitHub.