昨天在實戰表單模擬提交的時候，有發現在提交某個表單的時候，頁面（discuz！論壇）報錯，無法檢測到數據來源云云，但是我確實提交了http_referer了啊，怎么會出現這個情況呢？問了下haohappy,他給了個pear的類，http/client,才發現，我研究了幾天的東東，原來有個現成的可以用，“使用pear站在巨人的肩膀上”，這個果然沒有錯。過些天組裝一個client試試看。 ? 又扯遠了，書歸正傳，說研究一下一個另類的post頭，為什么說另類呢，因為一般的post頭的 Content-Type:?application/x-www-form-urlencoded 而他的是 Content-Type:?multipart/form-data; boundary=-------7d71f4234700b8 ? 那么兩者的區別又在那里呢？ ? 1、做過表單html的coder都知道，在需要有上傳文件操作的時候，表單的類型必須是enctype="multipart/form-data"，那么這里也就這個原因，究其根源，可以追溯到RFC1867協議,這個協議主要是在HTTP協議的基礎上為INPUT標簽增加了file屬性，同時限定了Form的method必須為POST，ENCTYPE必須為multipart/form-data。 ? 2、后者增加了boundary，所謂的boundary其實就是分割線，RFC1867利用boundary分割HTTP實體數據。boundary中數字字符區是隨機生成的。 ? 3、對HTTP實體的變更

因為RFC1867增加了文件上傳的功能，而上傳文件內容自然也會被加入到HTTP的實體中。現在因為既有HTTP一般的參數實體，又有上傳文件的實體，所以用boundary把每種實體進行了分割，HTTP的實體看起來將是類似下面的樣子：??

-----------------------------7d71f4234700b8
Content-Disposition: form-data; name="formhash"


59329e15
-----------------------------7d71f4234700b8
Content-Disposition: form-data; name="isblog"




-----------------------------7d71f4234700b8
Content-Disposition: form-data; name="fid"


104
-----------------------------7d71f4234700b8
Content-Disposition: form-data; name="subject"


test
-----------------------------7d71f4234700b8
Content-Disposition: form-data; name="iconid"


0
-----------------------------7d71f4234700b8
Content-Disposition: form-data; name="usesig"


1
-----------------------------7d71f4234700b8
Content-Disposition: form-data; name="message"


test
-----------------------------7d71f4234700b8
Content-Disposition: form-data; name="attachperm[]"


0
-----------------------------7d71f4234700b8
Content-Disposition: form-data; name="attachdesc[]"




-----------------------------7d71f4234700b8
Content-Disposition: form-data; name="attach[]"; filename=""
Content-Type: application/octet-stream




-----------------------------7d71f4234700b8
Content-Disposition: form-data; name="attachperm[]"


0
-----------------------------7d71f4234700b8
Content-Disposition: form-data; name="attachdesc[]"




-----------------------------7d71f4234700b8
Content-Disposition: form-data; name="attach[]"; filename=""
Content-Type: application/octet-stream




-----------------------------7d71f4234700b8
Content-Disposition: form-data; name="wysiwyg"


1
-----------------------------7d71f4234700b8--

很明顯，增加了文件上傳后，HTTP實體變得稍微復雜了，首先是通過boundary把實體分開，以便于讀取，然后對FileUpload的格式也作了限制。

?

4、那么同樣，這種格式也是需要提供Content-Length屬性的，那么和簡單的post數據頭相比較，就可以發現，變化的地方有：

......

Content-Type:

......
Content-Length:

......

數據體?goes here~

注意到這幾個地方的變化后，就可以像往常一樣post了

?

寫在最后的，在這個實戰post過程中，我使用了wsockexport這個軟件進行抓包操作，使得整個過程簡化了很多，在這里向作者表示敬意，（BTW：rising對其中的hook.dll似乎不怎么喜歡，大家用的時候，請關閉殺毒軟件，或者加入白名單）

總結

以上是生活随笔為你收集整理的【HTTP】另类的POST头数据 RFC1867协议格式简析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。