What causes "cannot parse r=%q: %w" in valyala/fasthttp?

Fix the r query parameter to be a valid Go regexp

cannot parse r=%q: %w

Error message

cannot parse r=%q: %w

What it means

fasthttpproxy's expvar handler accepts a query parameter r as a regexp to filter exported variables. If regexp.Compile fails on that value, the handler returns this wrapped error, quoting the invalid pattern and the underlying regexp parse error.

Source

Thrown at expvarhandler/expvar.go:61

				fmt.Fprintf(ctx, ",\n")
			}
			first = false
			fmt.Fprintf(ctx, "\t%q: %s", kv.Key, kv.Value)
		}
	})
	fmt.Fprintf(ctx, "\n}\n")

	ctx.SetContentType("application/json; charset=utf-8")
}

func getExpvarRegexp(ctx *fasthttp.RequestCtx) (*regexp.Regexp, error) {
	r := string(ctx.QueryArgs().Peek("r"))
	if r == "" {
		return defaultRE, nil
	}
	rr, err := regexp.Compile(r)
	if err != nil {
		return nil, fmt.Errorf("cannot parse r=%q: %w", r, err)
	}
	return rr, nil
}

View on GitHub (pinned to c96f600972)

Solutions

Fix the r query parameter to be a valid Go regexp
Escape special characters with regexp.QuoteMeta when building the URL programmatically
Simplify the pattern (use plain substrings that need no metacharacters)
Validate with regexp.Compile client-side before issuing the request

Example fix

// before
url := "/debug/vars?r=" + rawUserFilter // r="[abc"
// after
url := "/debug/vars?r=" + url.QueryEscape(regexp.QuoteMeta(rawUserFilter))

Defensive patterns

Strategy: validation

Validate before calling

if _, err := regexp.Compile(rParam); err != nil {
    http.Error(w, "invalid r parameter", http.StatusBadRequest)
    return
}

Type guard

func validRegex(s string) (*regexp.Regexp, bool) {
    re, err := regexp.Compile(s)
    return re, err == nil
}

Try / catch

re, err := getExpvarRegexp(ctx)
if err != nil {
    ctx.Error(fasthttp.StatusBadRequest, "invalid r parameter")
    return
}

Prevention

Escape user input with regexp.QuoteMeta before putting it in r
URL-encode the query parameter
Expose a documented set of preset filters instead of free-form regexps

When it happens

Trigger: Requesting /debug/vars?r=... with a syntactically invalid regular expression, e.g. r=[abc or r=* or r=(?P< unclosed group.

Common situations: Hand-typing filter patterns in a browser, dynamically building the r param from user input without escaping, copy-paste truncation of a pattern.

Related errors

AI-assisted analysis of valyala/fasthttp@c96f600972 (2026-08-31). Data as JSON: /api/errors/62ade8896906b212. Report an issue: GitHub.