Propagate multipart exceptions and accept custom charsets

[vincentjames501]

• In the previous implementation, when uploading a large file while the remote end hangs up it would throw an unhandled exception generally in the form "Read end dead"
• In the previous implementation, when uploading a file using an InputStream for example and the underlying stream throws an exception, these exceptions would not be propagated to the HttpClient/HttpRequest and would often result in incomplete payloads arriving to the server.
• Allow setting string charset types correctly where previously it would always use UTF-8 when copying to the underlying PipedOutputStream.

[gnarroway]

Thanks will take a look. Does this have any impact on https://github.com/gnarroway/hato/issues/55 ?

[vincentjames501]

Thanks will take a look. Does this have any impact on #55 ?

@gnarroway , it doesn't attempt to fix #55 . We likely want to loop through the parts and do our best to determine the content length of each part similar to how OkHttp does when determining the content length header. We can only report the content length if we can accurately determine the size of each part so it's fine if it's each part is a File/String/ByteArray/etc.

https://github.com/square/okhttp/blob/f9901627431be098ad73abd725fbb3738747461c/okhttp/src/jvmMain/kotlin/okhttp3/MultipartBody.kt#L109 https://github.com/square/okhttp/blob/f9901627431be098ad73abd725fbb3738747461c/okhttp/src/jvmTest/java/okhttp3/MultipartBodyTest.java#L27

[vincentjames501]

@gnarroway , I took a crack at addressing #55 . Appears to be working for me but could certainly use some smoke testing. CC @p-himik

[p-himik]

After a quick test, it seems to work just fine on my end, including the fix for #55.