在通常情況下，我們使用 CURL 來提交 POST 數(shù)據(jù)的時候，我們已經(jīng)習(xí)慣了這樣的寫法：

但是這樣的寫法在有時候并不會很好用，可能會得到服務(wù)器返回的 500 錯誤。但是我們嘗試在使用 Socket 方式向服務(wù)器提交數(shù)據(jù)的時候，我們會得到非常正確的結(jié)果。
例如我們在服務(wù)器上面存在一個如下的 PHP 文件：

當我們采用 CURL 在不注意細節(jié)的前提下向服務(wù)器發(fā)送一些數(shù)據(jù)，我們可能得到下面這樣的結(jié)果，這不是我們理想中的結(jié)果：

但是如果我們在采用 http_build_query($post_data) 來替代 $post_data 再向這個 PHP 腳本提交數(shù)據(jù)的時候，我們就會得到和上面不同的結(jié)果，這才是我們理想中的結(jié)果：

從上面這個例子中不難看出，使用 CURL 并且參數(shù)為數(shù)據(jù)時，向服務(wù)器提交數(shù)據(jù)的時候，HTTP頭會發(fā)送Content_type: application/x-www-form-urlencoded。這個是正常的網(wǎng)頁<form>提交表單時，瀏覽器發(fā)送的頭部。而 multipart/form-data 我們知道這是用于上傳文件的表單。包括了 boundary 分界符，會多出很多字節(jié)。
官方的手冊上是這樣說的：

使用數(shù)組提供 post 數(shù)據(jù)時，CURL 組件大概是為了兼容 @filename 這種上傳文件的寫法，默認把 content_type 設(shè)為了 multipart/form-data。雖然對于大多數(shù)服務(wù)器并沒有影響，但是還是有少部分服務(wù)器不兼容。
經(jīng)過一番總結(jié)最終得出結(jié)論：在沒有需要上傳文件的情況下，盡量對 post 提交的數(shù)據(jù)進行 http_build_query 處理，然后再發(fā)送出去，能實現(xiàn)更好的兼容性，更小的請求數(shù)據(jù)包。

最新評論