multipart/form-data parsing issues when providing a file that doesn't fit in a single chunk

[eth10]

After upgrading to connexion 3.x, which uses starlette instead of flask for request handling, if a client makes a request such as this:
curl -X 'POST' \ 'http://localhost/endpoint' -H 'accept: application/json' -H 'Content-Type: multipart/form-data' -F 'file=@Screenshot 2023-10-02 at 12.14.01 PM.png;type=image/png' -F 'description='

where a file is provided that doesn't fit in a single chunk of request.stream() then the underlying multipart library (which appears to be no longer supported...) inside starlette will endlessly loop through the fields as though there were infinite number of them until starlette reaches the specified max_fields/max_files and errors out whenever request.form() is called. This is an example output from debug logs of python-multipart:

Calling on_part_data with data[0:89]
Calling on_part_data with data[0:2]
Calling on_part_data with data[0:2]
Calling on_part_end with no data
Calling on_part_begin with no data
Calling on_header_field with data[137:156]
Calling on_header_value with data[158:235]
Calling on_header_end with no data
Calling on_header_field with data[237:249]
Calling on_header_value with data[251:260]
Calling on_header_end with no data
Calling on_headers_finished with no data
Calling on_part_data with data[264:15928]
Calling on_part_data with data[0:89]
Calling on_part_data with data[0:2]
Calling on_part_data with data[0:2]

you can see close toward the bottom where the index resets for some reason and it continues like this until the field count surpasses the max and an error is raised. Previously, the flask app from connexion 2.x would use the werkzeug multipart parsing and could handle this just fine.

In this example the file in question is about 40KB but you can see in the data call that it's only trying to handle about 16KB. Also the chunk size is not at all consistent and is my understanding that is determined by the client and not the server.