mach upload reports success without validating the HTTP response

[HenriqueSFernandes]

(the description was AI generated based on the conversation I had with it)

Problem

mach upload can print throughput metrics and exit successfully even when the server rejects or redirects the request. For example, an unauthenticated upload to an Access-protected endpoint receives HTTP 302, but the command still reports a successful-looking upload. The same behavior can hide responses such as 413 or 500.

CountingBody::Finished only means Hyper consumed the generated request body. It does not mean the server accepted it. ThroughputClient publishes InflightBody before awaiting the response, and the eventual response status is logged but never validated.

Expected behavior

The standalone upload command should only succeed when both conditions are true:

• The request body completed.
• The server returned a successful 2xx response.

Redirects for streaming POST requests should not be followed automatically. Non-2xx responses should produce a non-zero exit and include the HTTP status in the error.

Suggested approach

Preserve the early InflightBody needed for progress tracking, but expose a separate asynchronous response result containing the status, headers, or transport error. Initially consume it in mach upload; RPM and saturation can define their own failure policies separately.

Acceptance criteria

• 2xx upload responses succeed.
• 3xx, 4xx, and 5xx responses fail with the status shown.
• Request-body completion is not treated as HTTP success.
• HTTP/1 and HTTP/2 behavior is covered.
• Existing streaming/no-Content-Length behavior is preserved.

Priority / workaround

Low priority for the current investigation. Tests can use the regular public speed-test endpoint (https://h3.speed.cloudflare.com/__up) instead of the Access-protected staging environment.