*
 * Typical use loops over the parts in sequence:
 *
 * ```kotlin
 * val response: Response = call.execute()
 * val multipartReader = MultipartReader(response.body!!)
 *
 * multipartReader.use {
 *   while (true) {
 *     val part = multipartReader.nextPart() ?: break
 *     process(part.headers, part.body)
 *   }
 * }
 * ```
 *

}

public final class okhttp3/MultipartReader : java/io/Closeable {
	public fun <init> (Lokhttp3/ResponseBody;)V
	public fun <init> (Lokio/BufferedSource;Ljava/lang/String;)V
	public final fun boundary ()Ljava/lang/String;
	public fun close ()V
	public final fun nextPart ()Lokhttp3/MultipartReader$Part;
}

public final class okhttp3/MultipartReader$Part : java/io/Closeable {

}

public final class okhttp3/MultipartReader : java/io/Closeable {
	public fun <init> (Lokhttp3/ResponseBody;)V
	public fun <init> (Lokio/BufferedSource;Ljava/lang/String;)V
	public final fun boundary ()Ljava/lang/String;
	public fun close ()V
	public final fun nextPart ()Lokhttp3/MultipartReader$Part;
}

public final class okhttp3/MultipartReader$Part : java/io/Closeable {

    result in it OkHttp starting a thread for each queued task, even when a single thread could run
    all of them.

 *  Fix: Address a performance bug in `MultipartReader`. We were scanning the entire input stream
    for a delimiter when we only needed to scan enough to return a result.

 *  Fix: Don't double-compress the public suffix database. OkHttp is usually distributed in a