"--connect-timeout",
    help = "Maximum time allowed for connection (seconds)",
  ).int().default(DEFAULT_TIMEOUT)

  val readTimeout: Int by option("--read-timeout", help = "Maximum time allowed for reading data (seconds)").int().default(DEFAULT_TIMEOUT)

  val callTimeout: Int by option(
    "--call-timeout",
    help = "Maximum time allowed for the entire call (seconds)",
  ).int().default(DEFAULT_TIMEOUT)

      when (dot) {
        -1 -> length - labelStart
        else -> dot - labelStart
      }
    if (labelLength !in 1..63) return true
    if (dot == -1) break
    if (dot == length - 1) break // Trailing '.' is allowed.
    labelStart = dot + 1
  }

  return false
}

internal fun String.containsInvalidHostnameAsciiCodes(): Boolean {
  for (i in 0 until length) {
    val c = this[i]

   *
   * The target execution time is implemented on a best-effort basis. If another task in this queue
   * is running when that time is reached, that task is allowed to complete before this task is
   * started. Similarly the task will be delayed if the host lacks compute resources.
   *
   * @throws RejectedExecutionException if the queue is shut down and the task is not cancelable.
   */

  }

  @Test
  fun responseCodeDisagreesWithHeaders() {
    server.enqueue(
      MockResponse(
        code = HttpURLConnection.HTTP_NO_CONTENT,
        body = "This body is not allowed!",
      ),
    )
    assertFailsWith<IOException> {
      getResponse(newRequest("/"))
    }.also { expected ->
      assertThat(expected.message).isEqualTo("HTTP 204 had non-zero Content-Length: 25")

Socket writes are guarded by the Http2Writer. Only one stream can write at a time so that messages are not interleaved. Writes are either made by application-layer threads or the do-stuff-later pool.

### Holding multiple locks

You're allowed to take the Http2Connection lock while holding the Http2Writer lock. But not vice-versa. Because taking the Http2Writer lock can block.

### Events with Retries and Follow-Ups

OkHttp is resilient and can automatically recover from some connectivity failures. In this case, the `connectFailed()` event is not terminal and not followed by `callFailed()`. Event listeners will receive multiple events of the same type when retries are attempted.

      if (partCount == 0 && source.rangeEquals(0L, dashDashBoundary)) {
        // This is the first part. Consume "--" followed by the boundary.
        source.skip(dashDashBoundary.size.toLong())
      } else {
        // This is a subsequent part or a preamble. Skip until "\r\n--" followed by the boundary.
        while (true) {
          val toSkip = currentPartBytesRemaining(maxResult = 8192)

     * The file is newline separated. The first two lines are the URL and the request method. Next
     * is the number of HTTP Vary request header lines, followed by those lines.
     *
     * Next is the response status line, followed by the number of HTTP response header lines,
     * followed by those lines.
     *
     * HTTPS responses also contain SSL session information. This begins with a blank line, and then

    assertEquals(0, client.connectionPool.connectionCount())

    // Force reuse. This appears flaky (30% of the time) even though sessions are reused.
    // javax.net.ssl.SSLHandshakeException: No new session is allowed and no existing
    // session can be resumed
    //
    // Report https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8264944
    // Sessions improvement https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8245576

DEFAULT_JVM_OPTS='"-Xmx64m" "-Xms64m"'

# Collect all arguments for the java command:
#   * DEFAULT_JVM_OPTS, JAVA_OPTS, JAVA_OPTS, and optsEnvironmentVar are not allowed to contain shell fragments,
#     and any embedded shellness will be escaped.
#   * For example: A user cannot expect ${Hostname} to be expanded, as it is an environment variable and will be