aboutsummaryrefslogtreecommitdiff
path: root/tests/data/test654
AgeCommit message (Collapse)Author
2020-03-02mime: do not perform more than one read in a rowPatrick Monnerat
Input buffer filling may delay the data sending if data reads are slow. To overcome this problem, file and callback data reads do not accumulate in buffer anymore. All other data (memory data and mime framing) are considered as fast and still concatenated in buffer. As this may highly impact performance in terms of data overhead, an early end of part data check is added to spare a read call. When encoding a part's data, an encoder may require more bytes than made available by a single read. In this case, the above rule does not apply and reads are performed until the encoder is able to deliver some data. Tests 643, 644, 645, 650 and 654 have been adapted to the output data changes, with test data size reduced to avoid the boredom of long lists of 1-byte chunks in verification data. New test 664 checks mimepost using single-byte read callback with encoder. New test 665 checks the end of part data early detection. Fixes #4826 Reported-by: MrdUkk on github
2018-01-14mime: clone mime tree upon easy handle duplication.Patrick Monnerat
A mime tree attached to an easy handle using CURLOPT_MIMEPOST is strongly bound to the handle: there is a pointer to the easy handle in each item of the mime tree and following the parent pointer list of mime items ends in a dummy part stored within the handle. Because of this binding, a mime tree cannot be shared between different easy handles, thus it needs to be cloned upon easy handle duplication. There is no way for the caller to get the duplicated mime tree handle: it is then set to be automatically destroyed upon freeing the new easy handle. New test 654 checks proper mime structure duplication/release. Add a warning note in curl_mime_data_cb() documentation about sharing user data between duplicated handles. Closes #2235