Ok new version is out. simple smile

@yoavst: updated the demo project to 0.7

also, the String deserializer should respect the response encoding that is optionally provided with the content type

I used this, which is not bulletproof:

public val Response.contentTypeEncoding: String
    get() = contentTypeEncoding()

public fun Response.contentTypeEncoding(default: String = "utf-8"): String {
    val contentType: String = httpResponseHeaders["Content-Type"]?.first() ?: return default
    return contentType.substringAfterLast("charset=", default).substringAfter(' ', default)
}

You are right. Also, I think we should add

responseString(encoding)

https://github.com/kittinunf/Fuel/commit/9742984de91eec9d193d11150b532627c7f5ce72 Here is a support for setting charset to parse.

that was quick simple smile

Well,

String

has a constructor receiving

Charset

, and I used a custom

Deserializable

in one of my apps, so simple smile

Your code looks fine but my knowledge about HTTP headers is limited. Maybe @kittinunf knows more.

Using charset in content type header makes sense. However, the possibility is way too big. http://www.iana.org/assignments/character-sets/character-sets.xhtml

we should do it anyway we may wrap it with try catch in the case charset is unknown by Kotlin ..

is there a EAP build for 1025?

No, I was like waiting until Kotlin hits 1.0

Supposed to be one though 😞 my bad

@kittinunf: We need to release RC version simple smile

Yup I am rebuilding the lib

Somehow I am unable to sync 1.0.0-rc

Does anyone experience any problem or it is my internet connection?

I tried multiple times but it still doesn’t work - -"

I didn't have any problems

Oh @kittinunf You first have to update

Result

library.

That is why https://github.com/kittinunf/Fuel/pull/48 fails

Might be my internet connection last night. I am doing it again now

@kittinunf: I think I've found a bug.

In synchronized mode using sync(), it throws timeout exception if I put a breakpoint on success callback

So I think it counts the time you are on the callback as part of the time for the timeout.

In that case, we couldn’t do much? In practice, client won’t stay on like that?

Maybe there is heavy processing for the data.

@kittinunf:

Fuel.get("<https://www.google.co.il>").sync().timeout(5000).responseString { request, response, result ->
            println("Received; Start sleeping for 5 seconds.")
            Thread.sleep(5000)
            println("Done")
        }

will produce:

Received; Start sleeping for 5 seconds.
Exception in thread "main" java.util.concurrent.TimeoutException
	at java.util.concurrent.FutureTask.get(FutureTask.java:205)
	at com.github.kittinunf.fuel.core.DeserializableKt.response(Deserializable.kt:78)
	at com.github.kittinunf.fuel.core.DeserializableKt.response(Deserializable.kt:35)
	at com.github.kittinunf.fuel.core.Request.responseString(Request.kt:223)
	at com.github.kittinunf.fuel.core.Request.responseString$default(Request.kt:222)
	at com.yoavst.testing.fuel.SyncMethodBug.run(SyncMethodBug.kt:8)
	at com.yoavst.testing.MainKt.main(main.kt:7)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
Done

It doesn't seem to happen without

sync()