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

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.

    }

    /**
     * Test the service method when no Authorization header is present and no session exists.
     * Expects a 401 Unauthorized response with NTLM and Basic authentication challenges.
     * @throws ServletException
     * @throws IOException
     */
    @Test
    void testService_NoAuthHeader_NoSession() throws ServletException, IOException {
        ntlmServlet.init(servletConfig);

 *
 *  * [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.
 */

        // Since we can't mock the internal transport operations easily without real network,
        // we'll test the simpler case where no NTLM negotiation is needed
        when(request.getHeader("Authorization")).thenReturn(null);

        filter.doFilter(request, response, filterChain);

        // Should challenge the client

     * @param password the password to hash
     * @param challenge the server challenge bytes
     * @return the calculated response
     * @throws GeneralSecurityException if a cryptographic error occurs
     */
    public static byte[] getNTLMResponse(final String password, final byte[] challenge) throws GeneralSecurityException {
        return getNTLMResponse(getNTHash(password), challenge);
    }

    /**

    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
  }

   *
   * 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.)
   *

    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