Motivation and Context

1. ParallelPresignedUrlMultipartDownloaderSubscriber did not validate the first part's response metadata (Content-Length, Content-Range alignment). Parts 1+ were validated via validatePartResponse(), but part 0 only checked whether Content-Range was parseable — it never verified that the returned byte range and content length matched expectations.
2. Additionally, the subscriber had redundant error-forwarding logic, dead code on the success path
3. PresignedUrlMultipartDownloaderSubscriber had a misleading counter named completedParts that was actually used as a part index assignment counter (incremented before the request, not after completion)
4. Duplicate validation/request-building logic across both subscribers.
5. Content-Range validation used string prefix matching (startsWith) which is sensitive to whitespace formatting. RFC 7233 allows variable spacing in the Content-Range header.
6. forwardExceptionTo(resultFuture, response) was missing from sendFirstRequest, meaning part 0 wouldn't be cancelled if the download was cancelled externally (inconsistent with sendPartRequest and the regular ParallelMultipartDownloaderSubscriber).
7. parseStartByteFromContentRange was redundant after switching to regex-based validation — replaced with parseContentRange() which returns both start and end bytes for complete range validation.

Modifications

1. Added validatePartResponse(res, 0) call in sendFirstRequest to validate first part response (Content-Length, Content-Range alignment, start byte offset).
   Also renamed isCompletedExceptionally → downloadFailed for clarity and to avoid confusion with java.util.concurrent.CompletableFuture.isCompletedExceptionally().
2. Removed dead code: handlePartError(null, 0) on success path when download already failed.
   Separated error != null and downloadFailed.get() checks in sendPartRequest to avoid passing null to handlePartError. Added debug log for late completions.
3. Added [CompletableFutureUtils.forwardExceptionTo(resultFuture, response)](https://github.com/aws/aws-sdk-java-v2/pull/7013/changes#diff-eb746928a00e747ec260988bb77481373a53af2e2c11bc2918563b05ff11dd5aR143) in sendFirstRequest for consistency with sendPartRequest — ensures part 0 is cancelled if the download is cancelled externally.
4. Renamed completedParts → nextPartIndex in serial subscriber. Renamed totalComplete to dispatched.
5. Extracted shared validatePartResponse() and createRangedGetRequest() to PresignedUrlDownloadHelper.
   Moved calculateTotalParts() to MultipartDownloadUtils.
6. Replaced string prefix matching with regex-based Content-Range validation using MultipartDownloadUtils.parseContentRange().
   Removed parseStartByteFromContentRange (now redundant). Validates both start byte and end byte numerically.
   Improved error message to include part index and actual vs expected byte ranges.
7. Removed @immutable annotation from serial subscriber (class has mutable volatile fields).

Testing

1. Added 3 new tests to ParallelPresignedUrlMultipartDownloaderSubscriberTest:

• firstPartContentLengthMismatch_shouldFail — verifies Content-Length mismatch on part 0 is detected
• firstPartContentRangeStartByteMismatch_shouldFail — verifies wrong Content-Range start byte on part 0 is detected
• objectMutatedBetweenParts_shouldFailWith412 — verifies If-Match detects mid-download object mutation

2. Added PresignedUrlDownloadHelperTest — isolated unit tests for validatePartResponse() and createRangedGetRequest()
3. Added calculateTotalParts and parseContentRange tests to MultipartDownloadUtilsTest

Screenshots (if appropriate)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)

Checklist

• I have read the CONTRIBUTING document
• Local run of mvn install succeeds
• My code follows the code style of this project
• My change requires a change to the Javadoc documentation
• I have updated the Javadoc documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed
• I have added a changelog entry. Adding a new entry must be accomplished by running the scripts/new-change script and following the instructions. Commit the new file created by the script in .changes/next-release with your changes.
• My change is to implement 1.11 parity feature and I have updated LaunchChangelog

License

• I confirm that this pull request can be released under the Apache 2 license