[curl] Reject multipart parts spanning range gaps

[laxmanacharya8]

Summary

Reject a multipart byte-range part that would continue into a non-adjacent requested range. Previously, a malformed response such as Content-Range: bytes 0-19/... could fill requests for 0-9 and 100-109, silently writing bytes 10-19 into the second buffer.

Adjacent ranges remain supported because the HTTP request preprocessor coalesces them intentionally.

Add a loopback HTTP regression test that sends the malformed multipart response and verifies that the transfer fails before the second range is written.

Testing

• git diff --check
• Not run locally: this workspace has no configured ROOT build tree or CMake installation.

[github-actions]

Test Results

    23 files      23 suites   3d 13h 56m 48s ⏱️
 3 857 tests  3 855 ✅  0 💤 2 ❌
78 561 runs  78 549 ✅ 10 💤 2 ❌

For more details on these failures, see this check.

Results for commit f31481d.

[jblomer]

Thank you for the contribution! Interesting finding!

To better understand, can you explain how you discovered this bug or what was your intention in checking this code part?

[laxmanacharya8]

Thanks! I was doing an AI-assisted focused review of the HTTP multipart range-handling code, looking specifically for offset and boundary-validation issues. While tracing ProcessMultipartData, I noticed that after one requested range was filled, remaining bytes from the same multipart part could advance into the next range without checking whether the ranges were adjacent. I then confirmed the behavior with the 0-9 and 100-109 case and a Content-Range: bytes 0-19/... response.