PHP PECL_HTTP與cURL擴展

Question

我正在為CouchDB開發PHP客戶端。 瀏覽有關HTTP和cURL的php.net文檔時，我遇到了PECL_HTTP擴展。 乍一看，我認為我想使用此PECL擴展而不是cURL，因為它使用起來更簡單，而且我也不會做任何非常復雜的HTTP工作。 另外，我一直喜歡嘗試新事物，所以我不介意弄濕我的腳。

就我對StackOverflow社區的問題而言：

• 有沒有人同時使用PECL_HTTP和cURL擴展名？
• PECL擴展名是否存在任何嚴重的性能問題？
• PECL擴展名是否像在表面上一樣易於使用？
• 久經考驗的cURL庫是否仍然優越？

編輯：事實證明，PECL_HTTP擴展程序在后台使用了某些cURL源代碼，因此它們並不是完全不同的野獸。 兩者都是PHP的編譯擴展。

Answer 1

在我看來，CURL非常簡單易懂。 在PHP Cookbook（O'Reilly，2002年）中，出於各種（性能）原因選擇了CURL。

Answer 2

首先，我不得不說我們在公司使用過，從處理方面來說，我更喜歡php_http，我感謝Mike的工作。

但是我們放棄了php_http，因為它沒有捆綁在原始php中。 我們正在Windows環境中工作，對於每個php本身未捆綁的pecl擴展，我們必須自己進行編譯（這不是一件壞事）。 編譯時，我們收到一個錯誤，指出缺少某些標頭。 事實證明，這完全是我們的錯，因為在文檔中有明確說明。

自php_http 2.0版以來，它具有兩個非標准的依賴關系：-raphf 1.0.0或更高版本-propro 1.0.0或更高版本

因此，我們需要編譯的不僅僅是php_http。 但是對於propro 1.0.0（2013-08-12）config.w32在下載中丟失了（至少在編寫狀態下）。 因此，我們必須編寫自己的一個。 等等...

最后，我們讓它適用於PHP 5.5 VC11 x86，但是花了一些時間。 在公司中，有時您沒有時間花在這些事情上。 Curl總是開箱即用，因為它是捆綁在一起的。 這可能是不使用php_http的嚴重原因。

我真正要感謝的是php_http是否可以將其轉換為原始php。

希望這對一些決策者有所幫助;-)

Answer 3

事實證明，PECL_HTTP擴展使用起來更加簡單，在某些地方幾乎將我的代碼減少了一半。 :)

Answer 4

我還沒有嘗試過PECL_HTTP 。 我更喜歡使用cURL，因為我可以先在命令行中對其進行測試。 另外，cURL在標准linux安裝中可用，因此我可以期望它在各種基於linux的托管中可用。 我不知道PECL的可用性，因為我沒有在代碼中使用它的任何功能。