okhttp / okhttp3 / MultipartBody

MultipartBody

class MultipartBody :RequestBody

An RFC 2387-compliant request body.

Types

Name Summary
Builder class Builder
Part class Part

Properties

Name Summary
boundary val boundary:String
parts val parts:List<Part>
size The number of parts in this multipart body.val size:Int
type val type:MediaType

Functions

Name Summary
contentLength Returns the number of bytes that will be written to sink in a call to writeTo, or -1 if that count is unknown.fun contentLength():Long
contentType A combination of type and boundaryByteString.fun contentType():MediaType
part fun part(index:Int): Part
writeTo Writes the content of this request to sink.fun writeTo(sink:BufferedSink):Unit

Companion Object Properties

Name Summary
ALTERNATIVE The “multipart/alternative” type is syntactically identical to “multipart/mixed”, but the semantics are different. In particular, each of the body parts is an “alternative” version of the same information.val ALTERNATIVE:MediaType
DIGEST This type is syntactically identical to “multipart/mixed”, but the semantics are different. In particular, in a digest, the default Content-Type value for a body part is changed from “text/plain” to “message/rfc822”.val DIGEST:MediaType
FORM The media-type multipart/form-data follows the rules of all multipart MIME data streams as outlined in RFC 2046. In forms, there are a series of fields to be supplied by the user who fills out the form. Each field has a name. Within a given form, the names are unique.val FORM:MediaType
MIXED The “mixed” subtype of “multipart” is intended for use when the body parts are independent and need to be bundled in a particular order. Any “multipart” subtypes that an implementation does not recognize must be treated as being of subtype “mixed”.val MIXED:MediaType
PARALLEL This type is syntactically identical to “multipart/mixed”, but the semantics are different. In particular, in a parallel entity, the order of body parts is not significant.val PARALLEL:MediaType