This addresses #14 by providing a library implementation of asynchrony using threads and includes a lambda receiver callback mechanism (no promise based approach).

Usage is as follows:

khttp.async.get("https://www.google.com/") {
    println("Status Code: $statusCode")
    println("Response Text: $text")
}
// OR ...
khttp.async.get("https://www.google.com/", onError = {
   println("Error message: $message")
}, onResponse = {
    println("Status Code: $statusCode")
    println("Response Text: $text")
})

Each original library test is extended to apply to the corresponding async version.

Hopefully this approach adheres to the core design principles of the library and the provided implementation satisfies all necessary constraints.

Khttp has no supports for client side certificates yet. Providing a sslcontext option within the request parameter will enable the user to use a custom keymanager and trustmanager within the sslcontext. This will enable the user to load x amount of custom key materials and/or x amount of custom trust materials.

You can use it like this:

val sslContext: SSLContext = //initialized sslContext
val hostnameVerifier: HostnameVerifier = //initialized hostnameVerifier

println(get("https://github.com/", sslContext).text)

//or with hostnameVerifier
println(get("https://github.com/", sslContext, hostnameVerifier).text)

Within the pull requests I also updated all the dependencies and because of that I was also required to do some additional code changes. Please let me know this is ok or if I need to adjust the code a bit more.

This pull request will close the following feature requests: https://github.com/ascclemens/khttp/issues/64

Unsure if the problem is on my end, or if you didn't pay the monthly JitPack bill, but I can't get this to work:

@GrabResolver(name='jitpack.io', root='https://jitpack.io')
@Grab('com.github.jkcclemens:khttp:-SNAPSHOT')
import khttp

Error:

unable to resolve class khttp
   @GrabResolver(name='jitpack.io', root='https://jitpack.io/')
   ^

Hi,

Thank you for this awesome http client. I noticed that there is no option to pass a sslcontext and hostname verifier for ssl configuration. It would be great to have that option as well for https requests. Will there also be a support for SSLContext to configure the client?

Kinds regards, Hakan

This commit implements support for bearer token authorization.

It's a pretty naive implementation, I don't think there's much complexity here. Have added a simple unit test.

Hope this helps :)

I want to crawler somethings from other website,and I want to use khttp to do this job,but I do not know how to send a request to a website with proxys

We're writing a client for an API that uses "Content-Type: application/json; charset=utf-8". When we make a khttp.put request with this header, the request headers do not include the charset and instead uses the default header "Content-Type: application/json;" for a json parameter and "Content-Type: text/plain" for data.

I had trouble using JitPack, but those are my problems

The issue with khttp is that there is nowhere one can download actual compiled .jar for the library.

For example JCenter provides such an option, so I can use libs hosted there. I believe it is much easier to setup than Maven Central, you should look into it anyway.

Providing jars for some snapshots right on github is not a bad idea either.

Khttp has no supports for client side certificates yet. Providing a sslcontext option within the request parameter will enable the user to use a custom keymanager and trustmanager within the sslcontext. This will enable the user to load x amount of custom key materials and/or x amount of custom trust materials.

You can use it like this:

val sslContext: SSLContext = //initialized sslContext
val hostnameVerifier: HostnameVerifier = //initialized hostnameVerifier

println(get("https://github.com/", sslContext).text)

//or with hostnameVerifier
println(get("https://github.com/", sslContext, hostnameVerifier).text)

Within the pull requests I also updated all the dependencies and because of that I was also required to do some additional code changes. Please let me know this is ok or if I need to adjust the code a bit more.

This pull request will close the following feature requests: https://github.com/ascclemens/khttp/issues/64

It would be nice if you see as part of the installation something like:

repositories { ... maven { url "https://jitpack.io" } }

and then you can add the dependencie like:

dependencies { ... implementation "com.github.jkcclemens:khttp:master-SNAPSHOT" }

It's very easy but it will save people that want to use it on Android projects some time.

Regards I really like the project

This commit provides support for following HTTP 307 and HTTP 308 redirects. Specifically, the URL.openRedirectingConnection function (located in GenericResponse.kt) was updated to check for the HTTP response code's presence in an array of redirect response codes (301, 302, 303, 307, and 308). Previously, the function was only checking for response codes in the range 301..303.

For information regarding these additional HTTP status codes, see:

• 307 Temporary Redirect
• 308 Permanent Redirect

Fix #88 'Unable to make field private java.lang.String java.net.URL.host accessible: module java.base does not "opens java.net" to unnamed'

khttp version is 1.0.0

When calling HTTP PUT to a url, i keep getting below error

java.lang.reflect.InaccessibleObjectException: Unable to make field private java.lang.String java.net.URL.host accessible: module java.base does not "opens java.net" to unnamed module @5f5a92bb
        at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354) ~[na:na]
        at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297) ~[na:na]
        at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178) ~[na:na]
        at java.base/java.lang.reflect.Field.setAccessible(Field.java:172) ~[na:na]
        at khttp.requests.GenericRequest.toIDN(GenericRequest.kt:198) ~[khttp-1.0.0.jar!/:na]
        at khttp.requests.GenericRequest.makeRoute(GenericRequest.kt:208) ~[khttp-1.0.0.jar!/:na]
        at khttp.requests.GenericRequest.<init>(GenericRequest.kt:132) ~[khttp-1.0.0.jar!/:na]
        at khttp.KHttp.request(KHttp.kt:60) ~[khttp-1.0.0.jar!/:na]
        at khttp.KHttp.put(KHttp.kt:55) ~[khttp-1.0.0.jar!/:na]
        at khttp.KHttp.put$default(KHttp.kt:54) ~[khttp-1.0.0.jar!/:na]
        at ai.paravision.mozart.orchestrator.worker.WorkerClient.search$suspendImpl(WorkerClient.kt:29) ~[classes!/:0.0.0]

Is someone aware of alternative to this abandoned project?

(and yes, noone is obligated to maintain their open source project - but I prefer to use projects which are not dead, and while a bit offtopic it is not like this issue blocks or disturbs development)

Java is bad at HTTP. Really bad. The tools provided are functionally broken. Unfortunately, by extension, Kotlin is also bad at HTTP. Yet, more and more, the need to interact with APIs and perform basic HTTP requests shows up in programs, but the broken tools in Java make it a big fuss. This isn’t how it should be.

To combat this, libraries like Unirest have popped up, but they introduce massive amounts of overhead to just make a simple GET request.

khttp attempts to solve this problem, by mimicking the Python requests module. khttp uses only the org.json.json library and native Java. There’s nothing else. No bullshit.

from https://khttp.readthedocs.io/en/latest/ is very promising and I am looking exactly for something like this

Despite providing the Content-length as 0 by headers = mapOf("Content-length" to "0") it still gives the same error that the content length header is required.

We work in our project with Khttp and toady we have issue get the resource

Could not resolve khttp:khttp:0.1.0. > Could not get resource 'https://jcenter.bintray.com/khttp/khttp/0.1.0/khttp-0.1.0.pom'. > Could not GET 'https://jcenter.bintray.com/khttp/khttp/0.1.0/khttp-0.1.0.pom'. Received status code 502 from server: Bad Gateway

Can you update if you know on this? and estimate when it fixed?