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).

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
   Removed redundant CompletableFutureUtils.forwardExceptionTo — handlePartError already completes resultFuture and cancels in-flight requests
3. Renamed completedParts → nextPartIndex in PresignedUrlMultipartDownloaderSubscriber — the counter was incremented before the request was sent (to assign a part index), not after completion. The old name implied parts had finished downloading, which was misleading.
4. Extracted shared validatePartResponse() and createRangedGetRequest() to PresignedUrlDownloadHelper
   Moved calculateTotalParts() to MultipartDownloadUtils to eliminate duplication across both subscribers
5. Replaced string prefix matching with regex-based Content-Range validation using MultipartDownloadUtils.parseContentRange(). This handles RFC 7233 compliant formatting and validates both start byte and end byte numerically. Improved error message to include part index and actual vs expected byte ranges.
6. Added CompletableFutureUtils.forwardExceptionTo(resultFuture, response) in sendFirstRequest for consistency with sendPartRequest — ensures part 0 is cancelled if the download is cancelled externally.
7. Removed @immutable annotation from serial subscriber (class has mutable volatile fields — @threadsafe is correct).

Testing

• 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
• Added PresignedUrlDownloadHelperTest — isolated unit tests for validatePartResponse() and createRangedGetRequest()
• 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