Square’s meticulous HTTP client for the JVM, Android, and GraalVM.

Overview

OkHttp

See the project website for documentation and APIs.

HTTP is the way modern applications network. It’s how we exchange data & media. Doing HTTP efficiently makes your stuff load faster and saves bandwidth.

OkHttp is an HTTP client that’s efficient by default:

  • HTTP/2 support allows all requests to the same host to share a socket.
  • Connection pooling reduces request latency (if HTTP/2 isn’t available).
  • Transparent GZIP shrinks download sizes.
  • Response caching avoids the network completely for repeat requests.

OkHttp perseveres when the network is troublesome: it will silently recover from common connection problems. If your service has multiple IP addresses, OkHttp will attempt alternate addresses if the first connect fails. This is necessary for IPv4+IPv6 and services hosted in redundant data centers. OkHttp supports modern TLS features (TLS 1.3, ALPN, certificate pinning). It can be configured to fall back for broad connectivity.

Using OkHttp is easy. Its request/response API is designed with fluent builders and immutability. It supports both synchronous blocking calls and async calls with callbacks.

Get a URL

This program downloads a URL and prints its contents as a string. Full source.

OkHttpClient client = new OkHttpClient();

String run(String url) throws IOException {
  Request request = new Request.Builder()
      .url(url)
      .build();

  try (Response response = client.newCall(request).execute()) {
    return response.body().string();
  }
}

Post to a Server

This program posts data to a service. Full source.

public static final MediaType JSON
    = MediaType.get("application/json; charset=utf-8");

OkHttpClient client = new OkHttpClient();

String post(String url, String json) throws IOException {
  RequestBody body = RequestBody.create(JSON, json);
  Request request = new Request.Builder()
      .url(url)
      .post(body)
      .build();
  try (Response response = client.newCall(request).execute()) {
    return response.body().string();
  }
}

Further examples are on the OkHttp Recipes page.

Requirements

OkHttp works on Android 5.0+ (API level 21+) and Java 8+.

OkHttp depends on Okio for high-performance I/O and the Kotlin standard library. Both are small libraries with strong backward-compatibility.

We highly recommend you keep OkHttp up-to-date. As with auto-updating web browsers, staying current with HTTPS clients is an important defense against potential security problems. We track the dynamic TLS ecosystem and adjust OkHttp to improve connectivity and security.

OkHttp uses your platform's built-in TLS implementation. On Java platforms OkHttp also supports Conscrypt, which integrates BoringSSL with Java. OkHttp will use Conscrypt if it is the first security provider:

Security.insertProviderAt(Conscrypt.newProvider(), 1);

The OkHttp 3.12.x branch supports Android 2.3+ (API level 9+) and Java 7+. These platforms lack support for TLS 1.2 and should not be used. But because upgrading is difficult, we will backport critical fixes to the 3.12.x branch through December 31, 2021.

Releases

Our change log has release history.

The latest release is available on Maven Central.

implementation("com.squareup.okhttp3:okhttp:4.9.0")

Snapshot builds are available. R8 and ProGuard rules are available.

Also, we have a bill of materials (BOM) available to help you keep OkHttp artifacts up to date and be sure about version compatibility.

    dependencies {
       // define a BOM and its version
       implementation(platform("com.squareup.okhttp3:okhttp-bom:4.9.0"))
       
       // define any required OkHttp artifacts without version
       implementation("com.squareup.okhttp3:okhttp")
       implementation("com.squareup.okhttp3:logging-interceptor")
    }

MockWebServer

OkHttp includes a library for testing HTTP, HTTPS, and HTTP/2 clients.

The latest release is available on Maven Central.

testImplementation("com.squareup.okhttp3:mockwebserver:4.9.0")

GraalVM Native Image

Building your native images with Graal https://www.graalvm.org/ should work automatically. Please report any bugs or workarounds you find.

See the okcurl module for an example build.

$ ./gradlew okcurl:nativeImage
$ ./okcurl/build/graal/okcurl https://httpbin.org/get

License

Copyright 2019 Square, Inc.

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

   http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
Comments
  • Analytics API

    Analytics API

    We should add verbose logging for the response cache. Folks occasionally are puzzled when the cache doesn't work. Let's make it easy for them to figure out why.

    It would also be handy for debug panels and optimizers to monitor bytes in and out, connections created, etc.

    enhancement 
    opened by swankjesse 106
  • EOFException in RealBufferedSource.readUtf8LineStrict

    EOFException in RealBufferedSource.readUtf8LineStrict

    A few people have reported this. Needs investigation & fix.

    java.io.EOFException: null
        at okio.RealBufferedSource.readUtf8LineStrict(RealBufferedSource.java:154) ~[na:0.0]
        at com.squareup.okhttp.internal.http.HttpConnection.readResponse(HttpConnection.java:189) ~[na:0.0]
        at com.squareup.okhttp.internal.http.HttpTransport.readResponseHeaders(HttpTransport.java:101) ~[na:0.0]
        at com.squareup.okhttp.internal.http.HttpEngine.readResponse(HttpEngine.java:676) ~[na:0.0]
        at com.squareup.okhttp.internal.huc.HttpURLConnectionImpl.execute(HttpURLConnectionImpl.java:426) ~[na:0.0]
        at com.squareup.okhttp.internal.huc.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:371) ~[na:0.0]
        at com.squareup.okhttp.internal.huc.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:466) ~[na:0.0]
        at com.squareup.okhttp.internal.huc.DelegatingHttpsURLConnection.getResponseCode(DelegatingHttpsURLConnection.java:105) ~[na:0.0]
    
    bug 
    opened by swankjesse 100
  • EOFException in RealBufferedSource.readUtf8LineStrict(): 0-bytes in stream

    EOFException in RealBufferedSource.readUtf8LineStrict(): 0-bytes in stream

    We're getting an EOF exception with size=0 in the stream.

    java.io.EOFException: \n not found: size=0 content=...
                at okio.RealBufferedSource.readUtf8LineStrict(RealBufferedSource.java:200)
                at com.squareup.okhttp.internal.http.HttpConnection.readResponse(HttpConnection.java:187)
                at com.squareup.okhttp.internal.http.HttpTransport.readResponseHeaders(HttpTransport.java:80)
                at com.squareup.okhttp.internal.http.HttpEngine.readNetworkResponse(HttpEngine.java:791)
                at com.squareup.okhttp.internal.http.HttpEngine.access$200(HttpEngine.java:90)
    

    (Forked from issue 1114.)

    bug 
    opened by swankjesse 78
  • Unable to extract the trust manager

    Unable to extract the trust manager

    Hi, after upgrading from OkHttp 3.0.1 to 3.1.0 I get the following stack trace and crash after calling build() to create a OkHttpClient.

    java.lang.IllegalStateException: Unable to extract the trust manager on [email protected], sslSocketFactory is class com.google.android.gms.org.conscrypt.KitKatPlatformOpenSSLSocketAdapterFactory
                                                                            at okhttp3.OkHttpClient.<init>(OkHttpClient.java:187)
                                                                            at okhttp3.OkHttpClient.<init>(OkHttpClient.java:60)
                                                                            at okhttp3.OkHttpClient$Builder.build(OkHttpClient.java:719)
    

    This issue was not present in 3.0.1.

    Here's where the crash happens:

    OkHttpClient.Builder builder = new OkHttpClient.Builder()
                        .connectTimeout(10, TimeUnit.SECONDS)
                        .writeTimeout(10, TimeUnit.SECONDS)
                        .readTimeout(30, TimeUnit.SECONDS);
    
                OkHttpClient client = builder.build();
    
    bug 
    opened by AlexLardschneider 72
  • NoSuchElementException in RouteSelector

    NoSuchElementException in RouteSelector

    okhttp 3.7.0 retrofit 2.2.0

    All device brands and Android versions are reporting this issue.

    It happened for example after I tapped a notification, the app then makes a GET which ended in this exception. It didn't happen when I recreated the scenario. Device was Pixel, Android 7.1.2, on WLAN.

    java.util.NoSuchElementException
      at okhttp3.internal.connection.RouteSelector.next(RouteSelector.java:77)
      at okhttp3.internal.connection.StreamAllocation.findConnection(StreamAllocation.java:171)
      at okhttp3.internal.connection.StreamAllocation.findHealthyConnection(StreamAllocation.java:121)
      at okhttp3.internal.connection.StreamAllocation.newStream(StreamAllocation.java:100)
      at okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.java:42)
      at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
      at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:67)
      at okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.java:93)
      at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
      at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:67)
      at okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.java:93)
      at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
      at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.java:120)
      at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
      at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:67)
      at okhttp3.logging.HttpLoggingInterceptor.intercept(HttpLoggingInterceptor.java:211)
      at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
      at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:67)
      at com.readystatesoftware.chuck.ChuckInterceptor.intercept(ChuckInterceptor.java:167)
      at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
      at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:67)
      at com.myownpackage.manager.OkHttpManager$AuthenticationInterceptor.intercept(OkHttpManager.java:135)
      at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
      at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:67)
      at com.myownpackage.manager.OkHttpManager$NetworkLoggingInterceptor.intercept(OkHttpManager.java:190)
      at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
      at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:67)
      at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:185)
      at okhttp3.RealCall.execute(RealCall.java:69)
      at retrofit2.OkHttpCall.execute(OkHttpCall.java:174)
      at retrofit2.ExecutorCallAdapterFactory$ExecutorCallbackCall.execute(ExecutorCallAdapterFactory.java:89)
      at com.myownpackage.ui.ProfileFragment$11.doInBackground(ProfileFragment.java:516)
      at com.myownpackage.ui.ProfileFragment$11.doInBackground(ProfileFragment.java:511)
      at com.nanotasks.AbstractTask.doInBackground(AbstractTask.java:18)
      at com.nanotasks.AbstractTask.doInBackground(AbstractTask.java:7)
      at android.os.AsyncTask$2.call(AsyncTask.java:305)
      at java.util.concurrent.FutureTask.run(FutureTask.java:237)
      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607)
      at java.lang.Thread.run(Thread.java:761)
    
    opened by Jeff11 65
  • support enabling TLSv1.2 on Android 4.1-4.4.

    support enabling TLSv1.2 on Android 4.1-4.4.

    Our lawyers and security consultants claim that for PCI compliance*, we must disable TLS 1.0 and 1.1 on our servers. For some confusing reason, Android has supported TLS 1.2 since API 16 (android 4.1) but enabled it by default only since API 20 (android "4.4W").

    With okhttp 2.6, we were able to force use of TLS 1.2 with:

    OkHttpClient cli = new OkHttpClient();
    SSLContext sc = SSLContext.getInstance("TLSv1.2");
    sc.init(null, null, null);
    cli.setSslSocketFactory(new Tls12SocketFactory(sc.getSocketFactory()));
    ConnectionSpec cs = new ConnectionSpec.Builder(ConnectionSpec.MODERN_TLS)
            .tlsVersions(TlsVersion.TLS_1_2)
            .build();
    cli.setConnectionSpecs(ImmutableList.of(cs));
    

    where Tls12SocketFactory is this.

    However, okhttp 3.1 uses some kind of reflection on internal implementation details of the SSLSocketFactory, so the above implementation no longer works. And, indeed, it's a bit silly to make callers write so much code anyway. Specifying TLS_1_2 in the ConnectionSpec should be enough to get TLSv1.2 whenever it is supported.

    As far as I can tell, the only reason why the custom socket factory is needed in the first place is that ConnectionSpec.supportedSpec() calls SSLSocket.getEnabledProtocols() to learn the list of protocols supported by the system, so on Android 4.x where TLS 1.2 is supported but not enabled by default, OkHttp thinks 1.2 is not supported at all.

    Sorry for this long bug report: I think the fix is as simple as changing getEnabledProtocols() above to getSupportedProtocols() but wanted to submit this bug for discussion before making a PR with such a change, in case there is some affirmative reason why it's the other way now.

    * Originally I understood the PCI compliance deadline to be June 2016; however, it seems like it has since been changed to be June 2018. Regardless, OkHttp should support this change for users that want it.

    android 
    opened by mlc 63
  • WARNING: A connection to https://... was leaked. Did you forget to close a response body?

    WARNING: A connection to https://... was leaked. Did you forget to close a response body?

    Version: com.squareup.okhttp3:okhttp:3.0.1

    Log message:

    <timestamp> okhttp3.ConnectionPool pruneAndGetAllocationCount
    WARNING: A connection to https://... was leaked. Did you forget to close a response body?
    

    Code:

    private String get(final String url) {
        String res = null;
        try {
            final Request req = new Request.Builder().url(url).get().build();
            final Response resp = ok.newCall(req).execute();
            final int code = resp.code();
            if (code == 200) {
                final ResponseBody body = resp.body();
                res = body.string();
                body.close(); // even this doesn't work!
            }
        }
        catch (final Throwable th) {
            System.out.println(th.getMessage());
        }
        return res;
    }
    
    opened by bxqgit 62
  • ETag and If-None-Match

    ETag and If-None-Match

    I have troubles with the ETag-based caching. I am using OkHttp 1.5.4 and Retrofit 1.5.1 with HttpResponseCache set. There are logs below for better explanation.

    The request with the Session header set to a token A. OkHttp hits the network, which is great.

    ---> HTTP GET https://localhost/shares
    Session: TOKEN_A
    Accept: application/json
    User-Agent: Application/1.0.0 (Android 4.4.2; Nexus 4) Size/4.7 Resolution/1280x768
    ---> END HTTP (0-byte body)
    <--- HTTP 200 https://localhost/shares (402ms)
    : HTTP/1.1 200 OK
    Content-Length: 136
    Content-Type: application/json
    Date: Sat, 17 May 2014 11:07:20 GMT
    Etag: "677210f4c22a13203551e2b92a20684528a23c87"
    Last-Modified: Sat, 17 May 2014 04:07:20 GMT
    OkHttp-Received-Millis: 1400324839589
    OkHttp-Response-Source: NETWORK 200
    OkHttp-Sent-Millis: 1400324839194
    <--- END HTTP (136-byte body)
    

    The second request with the Session header set to a token A. OkHttp hits the cache, which is great as well.

    ---> HTTP GET https://localhost/shares
    Session: TOKEN_A
    Accept: application/json
    User-Agent: Application/1.0.0 (Android 4.4.2; Nexus 4) Size/4.7 Resolution/1280x768
    ---> END HTTP (0-byte body)
    GC_FOR_ALLOC freed 415K, 5% free 9588K/10036K, paused 19ms, total 19ms
    <--- HTTP 200 https://localhost/shares (46ms)
    : HTTP/1.1 200 OK
    Content-Length: 136
    Content-Type: application/json
    Date: Sat, 17 May 2014 11:07:20 GMT
    Etag: "677210f4c22a13203551e2b92a20684528a23c87"
    Last-Modified: Sat, 17 May 2014 04:07:20 GMT
    OkHttp-Received-Millis: 1400324839589
    OkHttp-Response-Source: CACHE 200
    OkHttp-Sent-Millis: 1400324839194
    <--- END HTTP (136-byte body)
    

    The third request with the Session header set to token B. OkHttp hits the cache again, which is not so great, because in this case the server returns a different response with a different ETag actually.

    ---> HTTP GET https://localhost/shares
    Session: TOKEN_B
    Accept: application/json
    User-Agent: Application/1.0.0 (Android 4.4.2; Nexus 4) Size/4.7 Resolution/1280x768
    ---> END HTTP (0-byte body)
    <--- HTTP 200 https://localhost/shares (11ms)
    : HTTP/1.1 200 OK
    Content-Length: 136
    Content-Type: application/json
    Date: Sat, 17 May 2014 11:07:20 GMT
    Etag: "677210f4c22a13203551e2b92a20684528a23c87"
    Last-Modified: Sat, 17 May 2014 04:07:20 GMT
    OkHttp-Received-Millis: 1400324839589
    OkHttp-Response-Source: CACHE 200
    OkHttp-Sent-Millis: 1400324839194
    <--- END HTTP (136-byte body)
    

    Personally I expect to see the If-None-Match at the second and the third requests. Is the issue related to the lack of Cache-Control header at servers’s responses? Maybe I just don’t understand the caching strategy properly.

    opened by arturdryomov 50
  • HTTP/2 uses non-daemon threads

    HTTP/2 uses non-daemon threads

    The following one-line program does not close properly on Java 9:

    public static void main(String[] args) throws IOException {
        System.out.println(new OkHttpClient.Builder().build().newCall(new Request.Builder().url("https://google.de").build()).execute());
    }
    

    It hangs for a very significant amount of time after the request is already finished before it allows the program to quit.

    This a little modified version works flawlessly and allows the program to quit immediately after the request is finished.

    public static void main(String[] args) throws IOException {
        System.out.println(new OkHttpClient.Builder().protocols(Collections.singletonList(Protocol.HTTP_1_1)).build().newCall(new Request.Builder().url("https://google.de").build()).execute());
    }
    

    Running on Java 8 also fixes the problem, as there HTTP 1.1 is used, not HTTP 2.0.

    The problem is a hanging non-deamon thread called OkHttp google.de. Here you have the stacktrace of the thread when the program should quit:

    "OkHttp [email protected]" prio=5 tid=0x11 nid=NA runnable
      java.lang.Thread.State: RUNNABLE
    	  at java.net.SocketInputStream.socketRead0(SocketInputStream.java:-1)
    	  at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
    	  at java.net.SocketInputStream.read(SocketInputStream.java:171)
    	  at java.net.SocketInputStream.read(SocketInputStream.java:141)
    	  at sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:425)
    	  at sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(SSLSocketInputRecord.java:65)
    	  at sun.security.ssl.SSLSocketImpl.bytesInCompletePacket(SSLSocketImpl.java:918)
    	  - locked <0x792> (a java.lang.Object)
    	  at sun.security.ssl.AppInputStream.read(AppInputStream.java:144)
    	  - locked <0x793> (a sun.security.ssl.AppInputStream)
    	  at okio.Okio$2.read(Okio.java:140)
    	  at okio.AsyncTimeout$2.read(AsyncTimeout.java:237)
    	  at okio.RealBufferedSource.request(RealBufferedSource.java:68)
    	  at okio.RealBufferedSource.require(RealBufferedSource.java:61)
    	  at okhttp3.internal.http2.Http2Reader.nextFrame(Http2Reader.java:95)
    	  at okhttp3.internal.http2.Http2Connection$ReaderRunnable.execute(Http2Connection.java:608)
    	  at okhttp3.internal.NamedRunnable.run(NamedRunnable.java:32)
    	  at java.lang.Thread.run(Thread.java:844)
    

    I find it quite strange that this thread is hanging on a socketRead operation, while the request is already finished successfully.

    enhancement 
    opened by Vampire 49
  • ProtocolException: unexpected end of stream while downloading a file

    ProtocolException: unexpected end of stream while downloading a file

    Using a library which uses okhttp to download files, I am usually getting an unexpected end of stream error while downloading large files (thrown at the end of the download). I am using the following code and URL to reproduce the error:

    OkHttpClient client = new OkHttpClient();
    Request request = new Request.Builder().url("http://speedtest-sfo1.digitalocean.com/100mb.test").build();
    client.newCall(request).enqueue(new Callback() {
    	public void onFailure(Call call, IOException e) {
    		e.printStackTrace();
    	}
    
    	public void onResponse(Call call, Response response) throws IOException {
    		if (!response.isSuccessful()) {
    			throw new IOException("Failed to download file: " + response);
    		}
    
    		FileOutputStream fos = new FileOutputStream(downloadDirectory + File.separator + "100mb.test");
    		fos.write(response.body().bytes());
    		fos.close();
    	}
    });
    

    URL: http://speedtest-sfo1.digitalocean.com/100mb.test (This is not the only URL the error is thrown on)

    The code has been tested on API 22, 25, 26, 27. The error is not thrown always, I tested it 10 times and got the error 6 times, 4 times the file got successfully downloaded and saved..

    I have read about the error and I know that it gets thrown when the servers sends incorrect Content-Length, not this time though. The file is exactly 100MB and the server supplies its correct length. I am not sending any extra request headers, the response headers are:

    Server => nginx/1.13.3
    Date => Sat, 09 Dec 2017 17:19:31 GMT
    Content-Type => text/plain
    Content-Length => 104857600
    Last-Modified => Mon, 27 Nov 2017 09:11:00 GMT
    Connection => close
    ETag => "5a1bd6a4-6400000"
    Access-Control-Allow-Origin => *
    Access-Control-Allow-Headers => Origin,X-RequestedWith,Content-Type,Range
    Access-Control-Allow-Methods => GET, OPTIONS
    Accept-Ranges => bytes
    Cache-Control => max-age=0, no-cache, no-store, mustrevalidate, no-transform
    
    

    The complete error:

    Callback failure for call to http://speedtest-sfo1.digitalocean.com/...
    java.net.ProtocolException: unexpected end of stream
        at okhttp3.internal.http1.Http1Codec$FixedLengthSource.read(Http1Codec.java:406)
        at okio.Buffer.writeAll(Buffer.java:1005)
        at okio.RealBufferedSource.readByteArray(RealBufferedSource.java:107)
        at okhttp3.ResponseBody.bytes(ResponseBody.java:136)
        at dm.com.downloadmanager.MainActivity$3.onResponse(MainActivity.java:273)
        at okhttp3.RealCall$AsyncCall.execute(RealCall.java:153)
        at okhttp3.internal.NamedRunnable.run(NamedRunnable.java:32)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
        at java.lang.Thread.run(Thread.java:764)
    
    needs info 
    opened by ali-idrizi 48
  • IOException in DiskLruCache in 1.5.0.

    IOException in DiskLruCache in 1.5.0.

    Upgraded to v1.5.0 and I'm seeing a lot of these exceptions thrown.

    java.lang.RuntimeException: java.io.IOException: failed to delete /data/data/app.philm.in/cache/picasso-cache/452f1b31c49eebbd77673818036d6560.0
           at com.squareup.okhttp.internal.DiskLruCache$1.run(DiskLruCache.java:175)
           at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
           at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
           at java.lang.Thread.run(Thread.java:841)
    Caused by: java.io.IOException: failed to delete /data/data/app.philm.in/cache/picasso-cache/452f1b31c49eebbd77673818036d6560.0
           at com.squareup.okhttp.internal.DiskLruCache.remove(DiskLruCache.java:584)
           at com.squareup.okhttp.internal.DiskLruCache.trimToSize(DiskLruCache.java:639)
           at com.squareup.okhttp.internal.DiskLruCache.access$100(DiskLruCache.java:86)
           at com.squareup.okhttp.internal.DiskLruCache$1.run(DiskLruCache.java:169)
           at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
           at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
           at java.lang.Thread.run(Thread.java:841)
    
    opened by chrisbanes 48
  • ConnectionPool builder

    ConnectionPool builder

    ConnectionPool is way more configurable (taskRunner + connection listener) and adding another public constructor is likely just going to become an n+1 treadmill.

    enhancement 
    opened by yschimke 0
  • [Discussion] Add more connection failure tracking and tests.

    [Discussion] Add more connection failure tracking and tests.

    Unlikely to be correct, but if the ConnectPlan is the right place, then a few more questions.

    • Are there more places for routeDatabase.failed?
    • Where should routeDatabase.connected be called?
    • Which exceptions indicate serious problems?

    RealConnection.trackFailure doesn't look right for HTTP/2.

    opened by yschimke 1
  • Loom Support

    Loom Support

    Project Loom, known as JEP 425 has published in JDK 19 as preview features.

    Spring community is also embracing the change.

    Tomcat also add support as preview feature

    Is there any roadmap for okhttp support it since it will be officially publish with JDK 21, probably at 09/23.

    enhancement 
    opened by techwnn 2
  • routeDatabase.failed is not called when we fail to establish a connection

    routeDatabase.failed is not called when we fail to establish a connection

    When we have two ways of connecting to a destination, say IPv4 and IPv6. If the IPv4 connection then fails (say EOF due to server dying), it gets marked in the routeDatabase as failed. If the IPv6 connection then fails to connect (say the server doesn't support IPv6), it does not get marked in the routeDatabase as failed. This means that ALL future connection attempts will be over IPv6. Which will all fail. Even though the IPv4 connection has come back up and is now stable.

    What we should do: also mark routes where we fail to establish a connection as failed. Then the IPv6 (in our example) route would also be marked as failed, and given that all routes have failed, they will all be tried again. Including the IPv4 connection which would then work when the server has recovered.

    bug 
    opened by moshegood 2
Ktorfit - a HTTP client/Kotlin Symbol Processor for Kotlin Multiplatform (Js, Jvm, Android, iOS, Linux) using KSP and Ktor clients inspired by Retrofit

Ktorfit is a HTTP client/Kotlin Symbol Processor for Kotlin Multiplatform (Js, Jvm, Android, iOS, Linux) using KSP and Ktor clients inspired by Retrofit

Jens Klingenberg 637 Dec 25, 2022
A js websocket server that handle an android app that connect to the sever with a QR code, to move a red square on a webpage with the gyroscope and accelerometer

online game a js websocket server with an express server, with a mobile app. backend express is used to handle the creation page, game page and the cr

null 2 Oct 7, 2021
LiteHttp is a simple, intelligent and flexible HTTP framework for Android. With LiteHttp you can make HTTP request with only one line of code! It could convert a java model to the parameter and rander the response JSON as a java model intelligently.

Android network framework: LiteHttp Tags : litehttp2.x-tutorials Website : http://litesuits.com QQgroup : 42960650 , 47357508 Android网络通信为啥子选 lite-htt

马天宇 829 Dec 29, 2022
Android Easy Http - Simplest android http request library.

Android Easy Http Library 繁體中文文檔 About Android Easy Http Library Made on OkHttp. Easy to do http request, just make request and listen for the respons

null 13 Sep 30, 2022
Asynchronous socket, http(s) (client+server) and websocket library for android. Based on nio, not threads.

AndroidAsync AndroidAsync is a low level network protocol library. If you are looking for an easy to use, higher level, Android aware, http request li

Koushik Dutta 7.3k Jan 2, 2023
Asynchronous Http and WebSocket Client library for Java

Async Http Client Follow @AsyncHttpClient on Twitter. The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and a

AsyncHttpClient 6k Jan 8, 2023
An android asynchronous http client built on top of HttpURLConnection.

Versions 1.0.0 1.0.1 1.0.2 1.0.3 1.0.4 1.0.5 1.0.6 Version 1.0.6 Description An android asynchronous http client based on HttpURLConnection. Updates U

David 15 Mar 29, 2020
Multiplatform coroutine-based HTTP client wrapper for Kotlin

networkinkt This is a lightweight HTTP client for Kotlin. It relies on coroutines on both JS & JVM platforms. Here is a simple GET request: val text =

Egor Zhdan 31 Jul 27, 2022
Kotlin DSL http client

Introduction Kotlin DSL http client Features ?? Developers Experience-driven library without verbosity. ?? Native way to use http client in Kotlin. ??

Sergei Rybalkin 461 Dec 13, 2022
Unirest in Java: Simplified, lightweight HTTP client library.

Unirest for Java Install With Maven: <!-- Pull in as a traditional dependency --> <dependency> <groupId>com.konghq</groupId> <artifactId>unire

Kong 2.4k Jan 5, 2023
Unirest in Java: Simplified, lightweight HTTP client library.

Unirest for Java Install With Maven: <!-- Pull in as a traditional dependency --> <dependency> <groupId>com.konghq</groupId> <artifactId>unire

Kong 2.4k Dec 24, 2022
A gRPC Kotlin based server and client starter that builds with Gradle and runs on the JVM

gRPC Kotlin starter Overview This directory contains a simple bar service written as a Kotlin gRPC example. You can find detailed instructions for bui

Hypto 8 Sep 19, 2022
Monitoring water tanker level using NodeMCU ESP8266 and HC-SR04P Ultrasonic Sensor and broadcasting it using a simple HTTP server inside NodeMCU ESP8266 and show data in an Android App

WaterLevel Preface This project aims to finding a tanker water level using NodeMCU with ESP8266 core and HC-SR04P Ultrasonic sensor and broadcasting i

YaMiN 12 Dec 20, 2022
Pluto is a on-device debugger for Android applications, which helps in inspection of HTTP requests/responses, capture Crashes and ANRs and manipulating application data on-the-go.

Pluto Pluto is a on-device debugger for Android applications, which helps in inspection of HTTP requests/responses, capture Crashes and ANRs and manip

Mocklets 8 Aug 22, 2022
Volley is an HTTP library that makes networking for Android apps easier and, most importantly, faster.

Volley Volley is an HTTP library that makes networking for Android apps easier and, most importantly, faster. For more information about Volley and ho

Google 3.3k Jan 1, 2023
HttpMocker is a simple HTTP mocking library written in Kotlin to quickly and easily handle offline modes in your apps

HttpMocker HttpMocker is a very lightweight Kotlin library that allows to mock HTTP calls relying on either OkHttp or the Ktor client libraries. It ca

David Blanc 174 Nov 28, 2022
Allows recording and playback http request/responses for testing purposes.

Allows recording and playback http request/responses for testing purposes.

Cristian Gómez 4 Aug 4, 2022
Allows recording and playback http request/responses for testing purposes.

Test Record Interceptor est Record Interceptor allows to record responses from http request to be replayed at tests. How it works Use regular http cal

Cristian Gómez 4 Aug 4, 2022
Ktor-Client this is the client part that uses the Ktor server

Ktor-Client this is the client part that uses the Ktor server Previews Tech stack & Open source libraries Minimum SDK level 21. Kotlin+ Coroutines + F

Mohamed Emad 4 Dec 23, 2022