根据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请求的工具或语言都可以支持，只是自己要稍微包装一下便可。