*
 * Supported on Android 2.3+.
 * Supported on JDK 8+ via Conscrypt.
 *
 * ### ALPN (Application Layer Protocol Negotiation)
 *
 * Supported on Android 5.0+.
 *
 * Supported on OpenJDK 8 via the JettyALPN-boot library or Conscrypt.
 *
 * Supported on OpenJDK 9+ via SSLParameters and SSLSocket features.
 *
 * ### Trust Manager Extraction
 *
 * Supported on Android 2.3+ and OpenJDK 7+. There are no public APIs to recover the trust

  }

  return null
}

@JvmField
internal val assertionsEnabled: Boolean = OkHttpClient::class.java.desiredAssertionStatus()

/**
 * Returns the string "OkHttp" unless the library has been shaded for inclusion in another library,
 * or obfuscated with tools like R8 or ProGuard. In such cases it'll return a longer string like
 * "com.example.shaded.okhttp3.OkHttp". In large applications it's possible to have multiple OkHttp

 *
 * Use [INSTANCE] for a task runner that uses daemon threads. There is not currently a shared
 * instance for non-daemon threads.
 *
 * The task runner is also responsible for releasing held threads when the library is unloaded.
 * This is for the benefit of container environments that implement code unloading.
 *
 * Most applications should share a process-wide [TaskRunner] and use queues for per-client work.
 */
class TaskRunner(

    `Headers` class offers full access to the HTTP headers.

 *  **Okio dependency added.** OkHttp now depends on
    [Okio](https://github.com/square/okio), an I/O library that makes it easier
    to access, store and process data. Using this library internally makes OkHttp
    faster while consuming less memory. You can write a `RequestBody` as an Okio
    `BufferedSink` and a `ResponseBody` as an Okio `BufferedSource`. Standard

  }

  @Test
  fun tls_stringCiphersAndVersions() {
    // Supporting arbitrary input strings allows users to enable suites and versions that are not
    // yet known to the library, but are supported by the platform.
    ConnectionSpec.Builder(ConnectionSpec.MODERN_TLS)
      .cipherSuites("MAGIC-CIPHER")
      .tlsVersions("TLS9k")
      .build()
  }

  @Test

 *  New: Switch our Internationalized Domain Name (IDN) implementation to [UTS #46 Nontransitional
    Processing][uts46]. With this fix, the `ß` code point no longer maps to `ss`. OkHttp now embeds
    its own IDN mapping table in the library.

 *  New: Prefer the client's configured precedence order for TLS cipher suites. (OkHttp used to
    prefer the JDK’s precedence order.) This change may cause your HTTP calls to negotiate a

common cipher suite and TLS version, your call will fail like this:

```
Caused by: javax.net.ssl.SSLProtocolException: SSL handshake aborted: ssl=0x7f2719a89e80:
    Failure in SSL library, usually a protocol error
        error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake
        failure (external/openssl/ssl/s23_clnt.c:770 0x7f2728a53ea0:0x00000000)

There are three kinds of compatibility we’re tracking:

 * **Binary compatibility** is the ability to compile a program against OkHttp 3.x, and then to run
   it against OkHttp 4.x. We’re using the excellent [japicmp][japicmp] library via its
   [Gradle plugin][japicmp_gradle] to enforce binary compatibility.

 * **Java source compatibility** is the ability to upgrade Java uses of OkHttp 3.x to 4.x without
   changing `.java` files.

 * selection to the underlying SSL socket.
 *
 * The configuration of each spec changes with each OkHttp release. This is annoying: upgrading
 * your OkHttp library can break connectivity to certain web servers! But it’s a necessary annoyance
 * because the TLS ecosystem is dynamic and staying up to date is necessary to stay secure. See