"jdflkasdf\", qop=\"auth\", stale=\"FALSE\"",
        ).build()
    val challenges = headers.parseChallenges("WWW-Authenticate")
    assertThat(challenges.size).isEqualTo(1)
    assertThat(challenges[0].scheme).isEqualTo("Digest")
    assertThat(challenges[0].realm).isEqualTo("myrealm")
    val expectedAuthParams = mutableMapOf<String, String>()
    expectedAuthParams["realm"] = "myrealm"

  /**
   * Returns the RFC 7235 authorization challenges appropriate for this response's code. If the
   * response code is 401 unauthorized, this returns the "WWW-Authenticate" challenges. If the
   * response code is 407 proxy unauthorized, this returns the "Proxy-Authenticate" challenges.
   * Otherwise this returns an empty list of challenges.
   *
   * If a challenge uses the `token68` variant instead of auth params, there is exactly one

Use `Response.challenges()` to get the schemes and realms of any authentication challenges. When fulfilling a `Basic` challenge, use `Credentials.basic(username, password)` to encode the request header.

=== ":material-language-kotlin: Kotlin"
    ```kotlin

  }

  @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(

   *
   * 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
  }

     * 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() {

 *  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

 *  New: `EventListener.followUpDecision()` is called each time a response is received. It notifies
    your listener if OkHttp has decided to make a follow-up request. Some common follow-ups are
    authentication challenges and redirects.

 *  New: Handy constants for `Headers.EMPTY`, `RequestBody.EMPTY`, and `ResponseBody.EMPTY`.

 *  New: OkHttp now calls `StrictMode.noteSlowCall()` when initializing TLS on Android. Use