我正在尋找C/C++的HTTP庫，它只處理協議邏輯，而不是實際的傳輸機制。我遇到的圖書館傾向於整合整個交流過程，這不是我需要的。C/C++ HTTP庫，僅處理邏輯？
但是，我正在尋找的不僅僅是一個HTTP解析器。理想情況下，它也會處理諸如會話/連接管理，複用等等的事情，只是它會留下應用程序執行的通信細節的實際實現。我正在查看客戶端和服務器端，但其中任何一個都會有所幫助。
最好我在找東西是免費的（非GPLed，但）。 HTTPS是一個優點。輕便是一個優點。簡單是一大優點。
任何這樣的事情？
問題是，一旦你希望它做會話管理，寫一個庫來包含傳輸（通常是套接字）直接處理，而不是嘗試定義應用程序可以實現的可用接口做潛在的運輸工作。特別是因爲大多數（顯然不是全部）用戶都需要這兩個組件。
我認爲你要找到的最好的東西就是以一種完全分離的方式實現它。沒有套接字實現的HTML服務器對世界上大多數人來說都是沒用的。我會尋找分開的代碼。下面是一個非常簡約的html服務器的例子，它似乎可以很好地分離，但並不完全確定，因爲我自己並沒有嘗試過，但是可以用你自己的實現和包裝器來替換套接字類，並且這樣做。
http://www.adp-gmbh.ch/win/misc/webserver.html
可能有其他的實施例在那裏爲好。一個好的谷歌搜索可能是你的朋友在這裏。無論如何，我不認爲你會找到一個完全斷開的服務器和客戶端，它們完全從他們使用的套接字實現中抽象出來。我以前不得不自己這樣做，編寫一個不使用套接字的html客戶端，而是將串行io用於另一臺設備，這會將數據傳遞到更廣泛的互聯網上。
如果你想要一個網絡服務器的子集讀取開源服務器的源代碼，並刪除你不需要的東西。你可能想看看lighttpd和nginx。它們是簡單輕量級的Web服務器。
做到這一點，它們都是不可讀/不可擦寫的增長的應用程序代碼。如果它不是從頭開始設計的圖書館，它就像圖書館一樣失敗。 – Lothar 2015-12-02 03:02:59
soup_session_sync_new()ne_session_create()soup_message_headers_foreach()和soup_message_body_flatten()build_request()公共）
+1，我從來沒有真正理解爲什麼庫總是傾向於在一個單芯片封裝中做的一切（libxml2的人？）。我也喜歡你的「免費（不是GPL）」態度。 – avakar 2010-01-14 15:32:17
爲什麼不是GPL？是否有法律/知識產權要求或只是個人偏好？ – ziya 2010-01-14 22:09:28
因爲沒有人需要一個XML Attributes庫，它除了屬性外別無其他。 – jmucchiello 2010-01-14 22:55:44