@Derk-Jan Karrenbeld some how, I found a way to fix the ByteArray Tests. it was assertEquals doesn't know how to handle Array.

com.github.[secure].fuel.core.requests.DownloadRequestTest > Download Big File FAILED org.mockserver.client.netty.SocketConnectionException Interesting

When I get a time, I will try to reduce of java imports.

@kittinunf I about to remove https://github.com/kittinunf/fuel/blob/master/fuel/src/main/kotlin/com/github/kittinunf/fuel/core/Encoding.kt from 3x 🙂

we are no longer need it?

It depends too much on Java class

if we wants to go Multiplatforms, Java Import deserve to be in JVM modules.

InputStream/OutputStream multiplatform alternative is https://github.com/Kotlin/kotlinx-io

let’s release another version for bug fixing …

i am running into:

> The inputs have already been written to an output stream and can not be consumed again.

when rying to use

FileDataPart

with

httpUpload

any other ways to debug what has been sent easily ?

other than intercepting the requests i guess, because i have no idea how to do that

okay it seems like when i passparameters into

"url".httpUpload("token" to token)

they just got ignored

due to

.cUrlString()

breaking that was not really clear

i think because the

.cUrlString()

read the stream once

so if you read it again, it throws error

maybe we have to correct the

cUrlString()

function

i think because the

.cUrlString()

read the stream once

We somewhere built this in. if you use

xxx

method, it actually stored the body in memory so you can re-use.

I also think it's documented somewhere

so i tried 2 ways.. if i run cUrlString() on the request and then trigger it , it fails on trigger

if i try to print the cUrlString in the repsonse handler it fails there

Then the bug is indeed in cUrlString()

I mean. it's not really a bug but alas 😛

the question if its a bug or not is debatable, i think it is.. since it causes crashes

It's not, because you're not supposed to use both cUrlString ánd a regular network request. Or at least that's how it's probably written right now. However, I think your use case is perfectly valid! That you want both 🙂

well i do that all the time.. to print the cUrlString when the request failed so i can test if some api i am using changed or broke down

yea, i love using

cUrlString()

too!

in case of eg. a binary blob in the request it would be fine to wite

-F @filename

i guess for that it would need to remember where the binary blob came from

otherwise i would probably just skip it and make sure the user understands there was stuff being skipped

or write it in base64 .. that might be a bit spammy though, depending on how much there is, and copying that to a terminal to try it out is also not easy then