}
    body.awaitSuccess()
    assertThat(log.take()!!)
      .contains("StreamResetException: stream was reset: CANCEL")
  }

  /**
   * We delay sending the last byte of the request body 1500 ms. The 1000 ms read timeout should
   * only elapse 1000 ms after the request body is sent.
   */
  @Test
  fun headersReadTimeoutDoesNotStartUntilLastRequestBodyByteFire() {

So, you will have to make sure your data is of the correct type. E.g. it is compatible with JSON, if you are returning a `JSONResponse`.

And also that you are not sending any data that should have been filtered by a `response_model`.

///

### More info { #more-info }

/// note | Technical Details

Consider an application streaming a video over http/2. Perhaps the user pauses the video and the application stops reading bytes from this stream. The buffer will fill up, and flow control prevents the server from sending more data on this stream. When the user unpauses her video the buffer drains, the read is acknowledged, and the server proceeds to stream data.

#### Shared reader thread

```
./gradlew clean check
```

Please make every effort to follow existing conventions and style in order to keep the code as
readable as possible.

Contribute code changes through GitHub by forking the repository and sending a pull request. We
squash all pull requests on merge.


Gradle Setup
------------

```
$ cat local.properties
sdk.dir=PATH_TO_ANDROID_HOME/sdk
org.gradle.caching=true
```

Running Android Tests

```
./gradlew clean check
```

Please make every effort to follow existing conventions and style in order to keep the code as
readable as possible.

Contribute code changes through GitHub by forking the repository and sending a pull request. We
squash all pull requests on merge.


Gradle Setup
------------

```
$ cat local.properties
sdk.dir=PATH_TO_ANDROID_HOME/sdk
org.gradle.caching=true
```

Running Android Tests

          .build(),
      )
    call1.execute().use { response -> response.body.string() }

    listener.shouldClose = true
    // Large headers are a likely reason the servers would cut off the connection before it completes sending
    // request headers.
    // 431 "Request Header Fields Too Large"
    val largeHeaders =
      Headers
        .Builder()
        .apply {
          repeat(32) {

   * [Call.request] is a redirect to a different address.
   */
  open fun connectionReleased(
    call: Call,
    connection: Connection,
  ) {
  }

  /**
   * Invoked just prior to sending request headers.
   *
   * The connection is implicit, and will generally relate to the last [connectionAcquired] event.
   *
   * This can be invoked more than 1 time for a single [Call]. For example, if the response to the

The process that happens when your API app calls the *external API* is named a "callback". Because the software that the external developer wrote sends a request to your API and then your API *calls back*, sending a request to an *external API* (that was probably created by the same developer).

                resp = new NtTransNotifyChangeResponse(th.getConfig());
            }

            if (log.isTraceEnabled()) {
                log.trace("Sending NtTransNotifyChange for " + this.handle);
            }
            try {
                resp = th.send(req, resp, RequestParam.NO_TIMEOUT, RequestParam.NO_RETRY);
            } catch (final SmbException e) {

For example, to declare a header of `X-Token` that can appear more than once, you can write:

{* ../../docs_src/header_params/tutorial003_an_py310.py hl[9] *}

If you communicate with that *path operation* sending two HTTP headers like:

```
X-Token: foo
X-Token: bar
```

The response would be like:

```JSON
{
    "X-Token values": [
        "bar",
        "foo"
    ]
}
```