根據http/1.1 rfc 2616的協議規定，我們的請求方式只有OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE等，那為為何我們還會有multipart/form-data請求之說呢？這就要從頭來說了。
http協議規定以ASCII碼傳輸，建立在tcp，ip協議智商的引用規范，規范內容把http請求分成3個部分，狀態行，請求頭，請求體。所有的方法，實現都是圍繞如何使用和組織這三部分來完成了，萬變不離其宗，http的知識大家可以問度娘。
既然上面請求方式里面沒有multipart/form-data那這個請求又是怎么回事呢，其實是一回事，multipart/form-data也是在post基礎上演變而來的，具體如下：
1.multipart/form-data的基礎方式是post，也就是說通過post組合方式來實現的。
2.multipart/form-data於post方法的不同之處在於請求頭和請求體。
3.multipart/form-data的請求頭必須包含一個特殊的頭信息：Content-Type，其值也必須為multipart/form-data，同時還需要規定一個內容分割用於分割請求提中多個post的內容，如文件內容和文本內容是需要分隔開來的，不然接收方就無法解析和還原這個文件了，具體的頭信息如下：
Content-Type: multipart/form-data; boundary=${bound}
其中${bound} 是一個占位符，代表我們規定的分割符，可以自己任意規定，但為了避免和正常文本重復了，盡量要使用復雜一點的內容。如：--------------------56423498738365
4.multipart/form-data的請求體也是一個字符串，不過和post的請求提不同的是它的構造方式，post是簡單的name=value鍵值連接，而multipart/form-data是添加了分隔符等內容的構造體，具體如下：
--${bound}
Content-Disposition: form-data; name="Filename"
HTTP.pdf
--${bound}
Content-Disposition: form-data; name="file000"; filename="HTTP協議詳解.pdf"
Content-Type: application/octet-stream
%PDF-1.5
file content
%%EOF
--${bound}
Content-Disposition: form-data; name="Upload"
Submit Query
--${bound}--
其中${bound}是之前頭信息中的分隔符，如果頭信息中規定是123，那這里也要是123；可以很容易看到，這個請求提是多個相同部分組成的：每一部分都是以--加分隔符開始的，然后是該部分內容的描述信息，然后一個回車，然后是描述信息的具體內容；如果傳送的內容是一個文件的話，那么還會包含文件名信息以及文件內容類型。上面第二部分是一個文件體的結構，最后以--分隔符--結尾，表示請求體結束。
可以知道要發送一個multipart/form-data的請求，其實任何支持post請求的工具或語言都可以支持，只是自己要稍微包裝一下便可
轉自 https://www.cnblogs.com/tylerdonet/p/5722858.html