首先來了解什么是multipart/form-data請求：
根據http/1.1rfc 2616的協議規定，我們的請求方式只有OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE等，那為為何我們還會有multipart/form-data請求之說呢？這就要從頭來說了。
http協議大家都知道是規定了以ASCII碼傳輸，建立在tcp、ip協議之上的應用層規范，規范內容把http請求分為3個部門：狀態行，請求頭，請求體。所有的方法、實現都是圍繞如何運用和組織這三部分來完成的。換句話來說就是萬變不離其中，只要我們了解了http請求的組成部分后，自然就可以應變任何實際工作中的需求和問題了。
關于狀態行，請求頭，請求體等三部分的具體內容，大家可以參考官方的協議文檔http://www.faqs.org/rfcs/rfc2616.html，這里主要分析multipart/form-data請求具體是怎么一回事。
既然http協議本身的原始方法不支持multipart/form-data請求，那這個請求自然就是由這些原始的方法演變而來的，具體如何演變且看下文：
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請求的工具或語言都可以支持，只是自己要稍微包裝一下便可。
真相如下：
用firefox上傳一個txt文件，內容為123test，用firebug查看網絡請求細節。
請求頭：
請求體：
http里沒有專門用于文件上傳的請求方式，文件上傳請求是在post請求基礎之上定義出來的一種方式。Multipart是HTTP協議為web表單新增的上傳文件的協議，協議文檔是rfc1867，它基于HTTP的POST方法，數據同樣是放在body上，跟普通POST方法的區別是數據不是key=value形式，key=value形式難以表示文件實體，為此Multipart協議添加了分隔符（即boundary的概念），有自己的格式結構
