What causes "authorization data parse error,ERR:%s" in snail007/goproxy?

Re-encode credentials as standard base64: `printf 'user:pass' | base64` and send `Authorization: Basic ` (prefer req.SetBasicAuth in Go clients).

snail007/goproxy · error

authorization data parse error,ERR:%s

Error message

authorization data parse error,ERR:%s

What it means

BasicAuth takes the second field of the Authorization header and decodes it with base64.StdEncoding.DecodeString. If the credential token is not valid standard base64, it throws "authorization data parse error,ERR:%s" wrapping the decode error, closes the connection, and returns.

Source

Thrown at utils/structs.go:326

func (req *HTTPRequest) BasicAuth() (err error) {

	//log.Printf("request :%s", string(b[:n]))
	authorization, err := req.getHeader("Authorization")
	if err != nil {
		fmt.Fprint((*req.conn), "HTTP/1.1 401 Unauthorized\r\nWWW-Authenticate: Basic realm=\"\"\r\n\r\nUnauthorized")
		CloseConn(req.conn)
		return
	}
	//log.Printf("Authorization:%s", authorization)
	basic := strings.Fields(authorization)
	if len(basic) != 2 {
		err = fmt.Errorf("authorization data error,ERR:%s", authorization)
		CloseConn(req.conn)
		return
	}
	user, err := base64.StdEncoding.DecodeString(basic[1])
	if err != nil {
		err = fmt.Errorf("authorization data parse error,ERR:%s", err)
		CloseConn(req.conn)
		return
	}
	authOk := (*req.basicAuth).Check(string(user))
	//log.Printf("auth %s,%v", string(user), authOk)
	if !authOk {
		fmt.Fprint((*req.conn), "HTTP/1.1 401 Unauthorized\r\n\r\nUnauthorized")
		CloseConn(req.conn)
		err = fmt.Errorf("basic auth fail")
		return
	}
	return
}
func (req *HTTPRequest) getHTTPURL() (URL string, err error) {
	if !strings.HasPrefix(req.hostOrURL, "/") {
		return req.hostOrURL, nil
	}
	_host, err := req.getHeader("host")

View on GitHub (pinned to e6d6a821db)

Solutions

Re-encode credentials as standard base64: `printf 'user:pass' | base64` and send `Authorization: Basic <result>` (prefer req.SetBasicAuth in Go clients).
Check the wrapped ERR for 'illegal base64 data' — it names the offending character/offset and pinpoints the bad token.
If a custom client uses URL-safe base64, switch it to StdEncoding, or patch the server to try RawURLEncoding/URLEncoding as a fallback.
Ensure nothing upstream truncates or reformats the header (check header size limits on fronting proxies).

Example fix

// before (server, strict decode only)
user, err := base64.StdEncoding.DecodeString(basic[1])

// after (server, tolerant decode)
user, err := base64.StdEncoding.DecodeString(basic[1])
if err != nil {
	user, err = base64.RawURLEncoding.DecodeString(basic[1])
	if err != nil {
		err = fmt.Errorf("authorization data parse error,ERR:%s", err)
		return
	}
}

Defensive patterns

Strategy: validation

Validate before calling

// client-side pre-check before sending credentials
token := base64.StdEncoding.EncodeToString([]byte(user + ":" + pass))
if _, err := base64.StdEncoding.DecodeString(token); err != nil {
	return fmt.Errorf("credential encoding failed: %w", err)
}
req.Header.Set("Authorization", "Basic "+token)

Type guard

func isStandardBase64(s string) bool {
	_, err := base64.StdEncoding.DecodeString(s)
	return err == nil
}

Try / catch

_, err := utils.NewHTTPRequest(conn, bufSize, true, auth)
if err != nil && strings.HasPrefix(err.Error(), "authorization data parse error") {
	log.Printf("Authorization token is not valid standard base64: %v", err)
	// advise client to re-encode with base64.StdEncoding
}

Prevention

Use req.SetBasicAuth() (Go) or equivalent stdlib helpers — never hand-roll the encoding.
Avoid URL-safe base64 (-/_) for HTTP Basic credentials; the server uses StdEncoding.
Beware double-encoding: encoding an already-encoded token also decodes to garbage.
Check intermediaries aren't truncating long Authorization headers.

When it happens

Trigger: Calling NewHTTPRequest with basic auth enabled when the client sends an Authorization header like "Basic <token>" where <token> contains characters outside the standard base64 alphabet (spaces, ':' as in raw user:pass, URL-safe -_ chars, or truncated padding).

Common situations: Clients sending raw "user:pass" (colon is invalid base64); credentials encoded with URL-safe base64 (RFC 4648 §5, '-'/'_') by a custom client; token truncated by an intermediate device or header length limit; missing '=' padding from hand-rolled encoders.

Understand the failure class

Parsing and encoding errors: unexpected token, malformed input — why parsers reject input and how to find the real culprit.

Related errors

AI-assisted analysis of snail007/goproxy@e6d6a821db (2026-09-03). Data as JSON: /api/errors/ed2e81aa3afab0c8. Report an issue: GitHub.