0x01.About
查看Restful API 報頭插件:Chrome插件REST Console,以及發送Restful API工具:Chrome插件POST Man
在HTTP 1.1規範中,HTTP請求方式有OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE、CONNECT
通常我們用的只有GET、POST,然而對於Restful API規範來說,請求資源要用PUT方法,刪除資源要用DELETE方法。
例如發送個DELETE包:
那麼通過id就能獲取到信息,這個包只有header,並不存在body,下面討論幾個包含body的發包的body傳輸格式。
0x02.Content-Type
Content-Type用於指定內容類型,一般是指網頁中存在的Content-Type,Content-Type屬性指定請求和響應的HTTP內容類型。如果未指定 ContentType,默認爲text/html。
在nginx中有個配置文件mime.types
,主要是標示Content-Type的文件格式。
下面是幾個常見的Content-Type:
1.text/html
2.text/plain
3.text/css
4.text/javascript
5.application/x-www-form-urlencoded
6.multipart/form-data
7.application/json
8.application/xml
…
前面幾個都很好理解,都是html,css,javascript的文件類型,後面四個是POST的發包方式。
0x03.application/x-www-form-urlencoded
application/x-www-form-urlencoded
是常用的表單發包方式,普通的表單提交,或者js發包,默認都是通過這種方式,
比如一個簡單地表單:
<form enctype="application/x-www-form-urlencoded" action="http://homeway.me/post.php" method="POST">
<input type="text" name="name" value="homeway">
<input type="text" name="key" value="nokey">
<input type="submit" value="submit">
</form>
那麼服務器收到的raw header會類似:
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip, deflate
Accept-Language:zh-CN,zh;q=0.8,en;q=0.6,zh-TW;q=0.4,gl;q=0.2,de;q=0.2
Cache-Control:no-cache
Connection:keep-alive
Content-Length:17
Content-Type:application/x-www-form-urlencoded
那麼服務器收到的raw body會是,name=homeway&key=nokey
,在php中,通過$_POST就可以獲得數組形式的數據。
0x04.multipart/form-data
multipart/form-data
用在發送文件的POST包。
這裏假設我用python的request發送一個文件給服務器:
data = {
"key1": "123",
"key2": "456",
}
files = {'file': open('index.py', 'rb')}
res = requests.post(url="http://localhost/upload", method="POST", data=data, files=files)
print res
通過工具,可以看到我發送的數據內容如下:
POST http://www.homeway.me HTTP/1.1
Content-Type:multipart/form-data; boundary=------WebKitFormBoundaryOGkWPJsSaJCPWjZP
------WebKitFormBoundaryOGkWPJsSaJCPWjZP
Content-Disposition: form-data; name="key2"
456
------WebKitFormBoundaryOGkWPJsSaJCPWjZP
Content-Disposition: form-data; name="key1"
123
------WebKitFormBoundaryOGkWPJsSaJCPWjZP
Content-Disposition: form-data; name="file"; filename="index.py"
這裏Content-Type
告訴我們,發包是以multipart/form-data
格式來傳輸,另外,還有boundary
用於分割數據。
當文件太長,HTTP無法在一個包之內發送完畢,就需要分割數據,分割成一個一個chunk發送給服務端,
那麼--
用於區分數據快,而後面的數據633e61ebf351484f9124d63ce76d8469
就是標示區分包作用。
0x05.text/xml
微信用的是這種數據格式發送請求的。
POST http://www.homeway.me HTTP/1.1
Content-Type: text/xml
<?xml version="1.0"?>
<resource>
<id>123</id>
<params>
<name>
<value>homeway</value>
</name>
<age>
<value>22</value>
</age>
</params>
</resource>
php中$_POST
只能讀取application/x-www-form-urlencoded
數據,$_FILES
只能讀取multipart/form-data
類型數據,
那麼,要讀取text/xml
格式的數據,可以用:
$file = fopen(‘php://input’, ‘rb’);
$data = fread($file, length);
fclose($file);
或者
$data = file_get_contents(‘php://input’);
0x06.application/json
通過json形式將數據發送給服務器,一開始,我嘗試通過curl,給服務器發送application/json
格式包,
然而我收到的數據如下:
————————–e1e1406176ee348a Content-Disposition: form-data; name=”nid” 2 ————————–e1e1406176ee348a Content-Disposition: form-data; name=”uuid” cf9dc994-a4e7-3ad6-bc54-41965b2a0dd7 ————————–e1e1406176ee348a Content-Disposition: form-data; name=”access_token” 956731586df41229dbfec08dd5d54eedb98d73d2 ————————–e1e1406176ee348a–
後來想想明白了,HTTP通信中並不存在所謂的json,而是將string轉成json罷了,也就是,application/json
可以將它理解爲text/plain
,普通字符串。
之所以出現那麼多亂七八糟的-------
應該是php數組傳輸進去,存在的轉換問題吧(我目前能想到的原因)。
本文出自 夏日小草,轉載請註明出處:http://homeway.me/2015/07/19/understand-http-about-content-type/
-by小草