Skip to content

Keep multipart header separators inside completed parts - #4

Open
kunal26das wants to merge 2 commits into
codex/kmp-native-gradientsfrom
codex/kmp-native-multipart-bounds
Open

Keep multipart header separators inside completed parts#4
kunal26das wants to merge 2 commits into
codex/kmp-native-gradientsfrom
codex/kmp-native-multipart-bounds

Conversation

@kunal26das

@kunal26das kunal26das commented Sep 10, 2026

Copy link
Copy Markdown
Owner

Summary

A multipart body ending in CRLF can produce a CRLFCRLF match that starts in the body and ends in the following boundary. MultipartStreamReader currently checks only the start of the match, then treats it as a header separator inside the completed part. This can create a negative body length and fail a development bundle download.

This native fork PR mirrors the upstream native multipart bounds submission as layer 4 of six. This layer is based on gradient calculations. The registered fork stack uses dependent PR bases, so this PR shows its incremental diff.

Stack order: FoundationRNTester dependenciesGradientsNative multipart boundsShared multipart parsingScroll offsets.

The existing Okio deprecation-suppression annotation from 35db533908c is placed with its regression in this layer. The native fix and annotation match the independently validated upstream submission; moving the annotation earlier leaves the final multipart and scroll source trees unchanged. The test results below retain their original source provenance and do not claim new execution solely from restacking.

Require the entire header separator to lie inside the part. Add a regression that reads the response at every possible chunk size, including binary content and boundary-like body bytes.

This is an existing native Android defect found while evaluating shared multipart parsing. The fix and regression are independent of Kotlin Multiplatform.

Changelog:

[ANDROID] [FIXED] - Keep multipart header separators inside their completed part.

Test Plan

  • Executed the real MultipartStreamReaderTest JUnit class with the original parser plus the new regression: the regression fails with negative body length.
  • Executed it with this one-line bounds fix: all seven tests pass, including every read size in the regression.
  • Repeated the isolated check with the exact final PR parser and seven-test file, the repository's Okio 2.9.0, Kotlin standard library 2.2.0, JUnit 4.13.2 and AssertJ 3.21.0: seven tests passed. The exact unchanged upstream parser with the same test file fails only the new regression. The fixture has no shared KMP JAR dependency. This does not claim Android device execution.

The assembled follow-up stack also passed the full ReactAndroid suite: 623 tests across 94 suites, zero failures/errors/skips. That run includes this bounds fix and regression, the shared multipart adapter, and other stack changes; it is not an isolated run of this PR. The regression suppresses a compile-time deprecation error to retain the reader's existing Okio 2.9 API usage.

The repository test entry point is :packages:react-native:ReactAndroid:testDebugUnitTest --tests com.facebook.react.devsupport.MultipartStreamReaderTest.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant