rqlite repairs authentication and redirected restore requests

A database client can authenticate an ordinary query correctly while failing on a different administrative request. It can also follow a redirect with the right URL but the wrong body. rqlite 5.5.1 addresses both kinds of incomplete request handling. The October 27 announcement describes fixes around Basic Authentication and backup and restore, while the tagged implementation shows how those failures arise at individual HTTP calls.

The common issue is that a client operation can involve several requests. Credentials need to accompany the relevant requests, and a restore payload needs to remain available when another server must receive it. Establishing the initial connection is insufficient if later steps lose inputs that define the operation. These corrections concern the client's actual execution path through the cluster.

I value rqlite's concise administrative interface, but its convenience depends on those paths being complete. A small command should still carry the intended authentication and payload through leader redirection. Otherwise the operator sees a failure whose cause lies in the client's request construction rather than in the database command itself.

Credentials belong on each required request

The release changelog identifies missing calls to set Basic Auth in the CLI. In this version, the client's shared request helper constructs each request and then attaches configured credentials before sending it. An invalid username/password representation produces an error, and the helper reports an unauthorized response explicitly.

The same source includes an authenticated path for fetching JSON used by client commands. Restore also has a preliminary status request, whose authentication appears in the backup and restore implementation. That preliminary request is part of restore even though it does not itself send the restored data.

This distinction explains why one successful authenticated operation does not prove all client functions are correct. Each HTTP request needs the appropriate credential behavior. A status fetch can fail before a later restore POST becomes possible. The fix adds missing behavior at those call sites without requiring a different database authorization model.

A redirect needs a fresh reader

Restore reads the selected file into a byte slice. It then passes a request-producing function to the shared helper. Each invocation constructs a new POST request using a new reader over those bytes. That is the key to preserving the body when the helper follows a leader redirect.

The changelog summarizes this as rereading the file on every attempt, but the implementation is more precise. The file is loaded into memory once for the operation, and the request body reader is recreated for each HTTP request. This avoids trying to reuse a reader whose contents the first request has already consumed. It also keeps the redirected payload tied to the bytes loaded for that restore.

The shared helper explicitly handles permanent redirects, updates the destination from the response and invokes the request producer again. It limits the number of redirects and rejects non-OK final responses. Reconstructing the request is therefore a deliberate part of client behavior, not an assumption that changing an address automatically restores a consumed body.

Backup distinguishes a follower from an unknown leader

The server backup handler checks the backup operation's result for ErrNotLeader. When the leader's API address is known, it redirects using the leader's protocol and address. When the address is unavailable, it responds with service unavailability. Other backup errors retain their separate error path.

These outcomes describe different states. A follower that knows the leader can tell the client where to continue. A node without that information cannot provide a usable destination merely because it accepted an HTTP connection. The new handling makes the distinction visible to the caller instead of treating every backup failure as the same server error.

The client writes a backup response to the selected file only after its request helper returns successfully. A SQL dump uses the same backup route with the SQL-format option. Those related operations benefit from the shared request handling, while restore remains a POST to the load endpoint with a raw text body.

Restore also consults database settings

The restore implementation reads the server's foreign-key setting from status and appends a corresponding pragma to the loaded restore bytes. It then sends those bytes and parses the result. That additional preparation is another reason to view restore as a sequence with explicit inputs rather than as one generic upload.

I prefer the request-producing helper because it keeps body reconstruction and credentials near the redirect loop that needs them. Each attempt receives a usable request, while backup's server response identifies whether another destination is available. Version 5.5.1 completes these paths so the command's requested data and authentication survive the transitions needed to reach the leader.