4. If it's a new route, it connects by building either a direct socket connection, a TLS tunnel (for HTTPS over an HTTP proxy), or a direct TLS connection. It does TLS handshakes as necessary. This step may be retried for tunnel challenges and TLS handshake failures.
 5. It sends the HTTP request and reads the response.

  }

  @Test
  fun challenge() {
    var challenge = Challenge("", mapOf("" to ""))
    challenge = Challenge("", "")
    val scheme: String = challenge.scheme
    val authParams: Map<String?, String> = challenge.authParams
    val realm: String? = challenge.realm
    val charset: Charset = challenge.charset
    val utf8: Challenge = challenge.withCharset(Charsets.UTF_8)
  }

  @Test

 *
 *  * [TCP handshake][connectSocket]
 *  * Optional [CONNECT tunnels][connectTunnel]. When using an HTTP proxy to reach an HTTPS server
 *    we must send a `CONNECT` request, and handle authorization challenges from the proxy.
 *  * Optional [TLS handshake][connectTls].
 *
 * Each step may fail. If a retry is possible, a new instance is created with the next plan, which
 * will be configured differently.
 */
class ConnectPlan(

A single HTTP call may require follow-up requests to be made to handle authentication challenges, redirects, and HTTP-layer timeouts. In such cases multiple connections, requests, and responses may be attempted. Follow-ups are another reason a single call may trigger multiple events of the same type.

   *
   * The network response's status code is most influential when deciding how to follow up:
   *
   *  * For redirects (301: Moved Permanently, 302: Temporary Redirect, etc.)
   *  * For auth challenges (401: Unauthorized, 407: Proxy Authentication Required.)
   *  * For client timeouts (408: Request Time-Out.)
   *  * For server failures (503: Service Unavailable.)
   *

    if (header.matches("\\d+".toRegex())) {
      return Integer.valueOf(header)
    }
    return Integer.MAX_VALUE
  }

  companion object {
    /**
     * How many redirects and auth challenges should we attempt? Chrome follows 21 redirects; Firefox,
     * curl, and wget follow 20; Safari follows 16; and HTTP/1.0 recommends 5.
     */
    private const val MAX_FOLLOW_UPS = 20
  }

    application code to omit a message.

 *  The challenge's scheme and realm are now non-null. If you are calling
    `new Challenge(scheme, realm)` you must provide non-null values. These were
    never null in challenges created by OkHttp, but could have been null in
    application code that creates challenges.

 *  New: The `TlsVersion` of a `Handshake` is now non-null. If you are calling

     * extracts the user principal from successful authentication.
     *
     * @return The login credential containing the authenticated username,
     *         an ActionResponseCredential for authentication challenges,
     *         or null if no authentication information is available
     * @throws SsoLoginException if SPNEGO authentication fails
     */
    @Override
    public LoginCredential getLoginCredential() {

          assertThat(response.code).isEqualTo(HttpURLConnection.HTTP_PROXY_AUTH)
          assertThat(response.request.url.host).isEqualTo("android.com")
          val challenges = response.challenges()
          assertThat(challenges[0].scheme).isEqualTo("OkHttp-Preemptive")
          response.request
            .newBuilder()
            .header("Proxy-Authorization", credential)
            .build()

 *  Fix: Limit to 20 authorization attempts.

## Version 2.1.0

_2014-11-11_

 *  New: Typesafe APIs for interacting with cipher suites and TLS versions.
 *  Fix: Don't crash when mixing authorization challenges with upload retries.


## Version 2.1.0-RC1

_2014-11-04_

 *  **OkHttp now caches private responses**. We've changed from a shared cache