* Generates tests of all methods on a {@code ByteSource} given various inputs the source is
 * expected to contain as well as sub-suites for testing the {@code CharSource} view and {@code
 * slice()} views in the same way.
 *
 * @author Colin Decker
 */
@AndroidIncompatible // TODO(b/230620681): Make this available (even though we won't run it).
public class ByteSourceTester extends SourceSinkTester<ByteSource, byte[], ByteSourceFactory> {

  </dependencies>
  <build>
    <resources>
      <resource>
        <directory>..</directory>
        <includes>
          <include>LICENSE</include> <!-- copied from the parent pom because I couldn't figure out a way to make combine.children="append" work -->
          <include>proguard/*</include>
        </includes>
        <targetPath>META-INF</targetPath>
      </resource>
    </resources>
    <plugins>
      <plugin>

     * In the case of Java tools, the map may also contain {@code --patch-module} options, which are
     * {@linkplain org.apache.maven.api.JavaPathType#patchModule(String) handled in a special way}.
     *
     * <h4>Design note</h4>
     * All types of path are determined together because they are sometime mutually exclusive.
     * For example, an artifact of type {@value org.apache.maven.api.Type#JAR} can be placed

      assertWrapsInterruptedException(expected);
    } finally {
      interruptenator.shutdown();
      Thread.interrupted();
    }
  }

  /**
   * awaitFullGc() is not quite as reliable a way to ensure calling of a specific finalize method as
   * the more direct await* methods, but should be reliable enough in practice to avoid flakiness of
   * this test. (And if it isn't, we'd like to know about it first!)
   */

# Header Parameters

You can define Header parameters the same way you define `Query`, `Path` and `Cookie` parameters.

## Import `Header`

First import `Header`:

//// tab | Python 3.10+

```Python hl_lines="3"
{!> ../../docs_src/header_params/tutorial001_an_py310.py!}
```

////

//// tab | Python 3.9+

```Python hl_lines="3"
{!> ../../docs_src/header_params/tutorial001_an_py39.py!}
```

////

And if you update that local FastAPI source code when you run that Python file again, it will use the fresh version of FastAPI you just edited.

That way, you don't have to "install" your local version to be able to test every change.

/// note | "Technical Details"

        // configuration. We don't have an easy way to allow a pluggable builder to provide its own configuration
        // parameters but this is sufficient for now. Ultimately we want components like Builders to provide a way to
        // extend the command line to accept its own configuration parameters.
        //

B,IAAkB,CAAlBA,ECLT,iBAAoD,IAE9CH,MAAMC,SAAND,CAAgBI,gBACXD,GAAIC,SAAJD,CAAc,kBAAOE,SAArB,CAAAF,KAIHG,GAAQJ,IAAU,kBAAOK,SAAjB,CAAAL,QACPC,GAAInI,OAAJmI,ICLT,iBAA4D,IACpDK,GAAiBC,aAEnBC,EAAUC,KAAVD,CAAgB,CAAhBA,CAAmBN,IAAqB,MAArBA,GAAnBM,WAEWE,QAAQ,WAAY,CAC7B9G,EAAS,UAATA,CAD6B,UAEvB+G,KAAK,wDAFkB,IAI3BC,GAAKhH,EAAS,UAATA,GAAwBA,EAASgH,GACxChH,EAASiH,OAATjH,EAAoBkH,IALS,KAS1BpG,QAAQ4C,OAAS7B,EAAcsF,EAAKrG,OAALqG,CAAazD,MAA3B7B,CATS,GAU1Bf,QAAQrD,UAAYoE,EAAcsF,EAAKrG,OAALqG,CAAa1J,SAA3BoE,CAVM,GAY...

        that actually comes up in the real world. We want to hear the real-world use case so the
        community can discuss and debate whether this feature is actually the *best* way to address
        the real use case, or whether or not a different abstraction might be more appropriate.


        It's okay if you can't provide complete context on a use case. We understand if you are not

}

func newExitCodeFilter(w io.Writer) (*exitCodeFilter, string) {
	const exitStr = "exitcode="

	// Build a regexp that matches any prefix of the exit string at the end of
	// the input. We do it this way to avoid assuming anything about the
	// subcommand output (e.g., it might not be \n-terminated).
	var exitReStr strings.Builder
	for i := 1; i <= len(exitStr); i++ {
		fmt.Fprintf(&exitReStr, "%s$|", exitStr[:i])
	}