Function probe_priming 

pub async fn probe_priming(
    client: &Client,
    url: &Url,
    prime: Option<u64>,
) -> Result<Primed, TransferError>

Probe and start the download in a single request.

probe asks for bytes=0-0, reads one byte, throws it away, and only then lets the real work begin — one whole round trip of pure overhead on every download, which is why rget could never match a single-request client on a small file. This asks for bytes=0- instead: the reply tells us everything probe would have, and its body is the beginning of the file.

The three answers a server can give, all useful:

• 206 with a parseable Content-Range — ranges work, size known, and the first bytes are already streaming.
• 200 — the server ignored Range and sent the whole representation. The body still starts at byte 0, so it still primes the transfer. Whether we may also issue ranged requests is then down to Accept-Ranges.
• anything else — fall back to [plain_probe] and hand back no body.

prime bounds how much of the file the probe asks for.

None means bytes=0- — the whole file — which is right when one connection is going to transfer all of it anyway. Some(n) asks for the first n bytes, which is what a parallel download wants: the body is then exactly the first range of the plan (see crate::scheduler::plan_primed) and nothing the server sends is discarded. An open-ended prime in a parallel download would stream the entire file down a connection whose worker stops at the first chunk boundary, wasting 3–8% of the transfer.