『壹』 https /SSL 發送POST請求的格式是怎麼樣的呢
SSL (Secure Socket Layer)
為Netscape所研發，用以保障在Internet上數據傳輸之安全，利用數據加密(Encryption)技術，可確保數據在網路
上之傳輸過程中不會被截取及竊聽。目前一般通用之規格為40 bit之安全標准，美國則已推出128 bit之更高安全
標准，但限制出境。只要3.0版本以上之I.E.或Netscape瀏覽器即可支持SSL。
當前版本為3.0。它已被廣泛地用於Web瀏覽器與伺服器之間的身份認證和加密數據傳輸。
SSL協議位於TCP/IP協議與各種應用層協議之間，為數據通訊提供安全支持。SSL協議可分為兩層： SSL記錄協議（SSL Record Protocol）：它建立在可靠的傳輸協議（如TCP）之上，為高層協議提供數據封裝、壓縮、加密等基本功能的支持。 SSL握手協議（SSL Handshake Protocol）：它建立在SSL記錄協議之上，用於在實際的數據傳輸開始前，通訊雙方進行身份認證、協商加密演算法、交換加密密鑰等。
SSL協議提供的服務主要有：
1）認證用戶和伺服器，確保數據發送到正確的客戶機和伺服器；
2）加密數據以防止數據中途被竊取；
3）維護數據的完整性，確保數據在傳輸過程中不被改變。
SSL協議的工作流程：
伺服器認證階段：1）客戶端向伺服器發送一個開始信息「Hello」以便開始一個新的會話連接；2）伺服器根據客戶的信息確定是否需要生成新的主密鑰，如需要則伺服器在響應客戶的「Hello」信息時將包含生成主密鑰所需的信息；3）客戶根據收到的伺服器響應信息，產生一個主密鑰，並用伺服器的公開密鑰加密後傳給伺服器；4）伺服器恢復該主密鑰，並返回給客戶一個用主密鑰認證的信息，以此讓客戶認證伺服器。
用戶認證階段：在此之前，伺服器已經通過了客戶認證，這一階段主要完成對客戶的認證。經認證的伺服器發送一個提問給客戶，客戶則返回（數字）簽名後的提問和其公開密鑰，從而向伺服器提供認證。
從SSL 協議所提供的服務及其工作流程可以看出，SSL協議運行的基礎是商家對消費者信息保密的承諾，這就有利於商家而不利於消費者。在電子商務初級階段，由於運作電子商務的企業大多是信譽較高的大公司，因此這問題還沒有充分暴露出來。但隨著電子商務的發展，各中小型公司也參與進來，這樣在電子支付過程中的單一認證問題就越來越突出。雖然在SSL3.0中通過數字簽名和數字證書可實現瀏覽器和Web伺服器雙方的身份驗證，但是SSL協議仍存在一些問題，比如，只能提供交易中客戶與伺服器間的雙方認證，在涉及多方的電子交易中，SSL協議並不能協調各方間的安全傳輸和信任關系。在這種情況下，Visa和 MasterCard兩大信用卡公組織制定了SET協議，為網上信用卡支付提供了全球性的標准。
https介紹
HTTPS（Secure Hypertext Transfer Protocol）安全超文本傳輸協議
它是由Netscape開發並內置於其瀏覽器中，用於對數據進行壓縮和解壓操作，並返回網路上傳送回的結果。HTTPS實際上應用了Netscape的完全套接字層（SSL）作為HTTP應用層的子層。（HTTPS使用埠443，而不是象HTTP那樣使用埠80來和TCP/IP進行通信。）SSL使用40 位關鍵字作為RC4流加密演算法，這對於商業信息的加密是合適的。HTTPS和SSL支持使用X.509數字認證，如果需要的話用戶可以確認發送者是誰。。
https是以安全為目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，https的安全基礎是SSL，因此加密的詳細內容請看SSL。
它是一個URI scheme(抽象標識符體系)，句法類同http:體系。用於安全的HTTP數據傳輸。https:URL表明它使用了HTTP，但HTTPS存在不同於HTTP的默認埠及一個加密/身份驗證層（在HTTP與TCP之間）。這個系統的最初研發由網景公司進行，提供了身份驗證與加密通訊方法，現在它被廣泛用於萬維網上安全敏感的通訊，例如交易支付方面。
限制
它的安全保護依賴瀏覽器的正確實現以及伺服器軟體、實際加密演算法的支持.
一種常見的誤解是「銀行用戶在線使用https:就能充分徹底保障他們的銀行卡號不被偷竊。」實際上，與伺服器的加密連接中能保護銀行卡號的部分，只有用戶到伺服器之間的連接及伺服器自身。並不能絕對確保伺服器自己是安全的，這點甚至已被攻擊者利用，常見例子是模仿銀行域名的釣魚攻擊。少數罕見攻擊在網站傳輸客戶數據時發生，攻擊者嘗試竊聽數據於傳輸中。
商業網站被人們期望迅速盡早引入新的特殊處理程序到金融網關，僅保留傳輸碼(transaction number)。不過他們常常存儲銀行卡號在同一個資料庫里。那些資料庫和伺服器少數情況有可能被未授權用戶攻擊和損害。
『貳』 GET和POST可傳遞的值到底有多大
get 是通過URL提交數據，因此GET可提交的數據量就跟URL所能達到的最大長度有直接關系。很多文章都說GET方式提交的數據最多隻能是1024位元組，而實際上，URL不存在參數上限的問題，HTTP協議規范也沒有對URL長度進行限制。這個限制是特定的瀏覽器及伺服器對它的限制。IE對URL長度的限制是2083位元組(2K+35位元組)。對於其他瀏覽器，如FireFox，Netscape等，則沒有長度限制，這個時候其限製取決於伺服器的操作系統。即如果url太長，伺服器可能會因為安全方面的設置從而拒絕請求或者發生不完整的數據請求。
post 理論上講是沒有大小限制的，HTTP協議規范也沒有進行大小限制，但實際上post所能傳遞的數據量大小取決於伺服器的設置和內存大小。因為我們一般post的數據量很少超過MB的，所以我們很少能感覺的到post的數據量限制，但實際中如果你上傳文件的過程中可能會發現這樣一個問題，即上傳個頭比較大的文件到伺服器時候，可能上傳不上去，以php語言來說，查原因的時候你也許會看到有說PHP上傳文件涉及到的參數PHP默認的上傳有限定，一般這個值是2MB，更改這個值需要更改php.conf的post_max_size這個值。這就很明白的說明了這個問題了。
『叄』 http post和get可以混用嗎
http post可以和get混用。
問題來源於get和post的特點和限制。對於get請求，可以很方便的使用window.opener的方式與父頁面進行通訊，但是根據http協議的規定，但在IE中，url最大長度是2083個位元組,可以用於GET傳遞數據的長度是2048個位元組。對於post請求，雖然沒有最大長度的限制，卻不能方便的使用window.opener與父頁面進行通訊。
關於如何使用javascript自動將一段get請求轉變成一個post請求，網上有很多的方法，其主要思想就是動態構造一個iframe，並將get請求中的url參數值賦給input控制項，最後設置form的action地址並調用submit方法。
『肆』 對於https協議的網站，可以用php 的curl來模擬get請求和post請求嗎，能得到返回值嗎
可以。
CURLOPT_PROTOCOLS
CURLPROTO_* 的位域指。如果被啟用，位域值會限定libcurl在傳輸過程中有哪些可使用的協議。這將允許你在編譯libcurl時支持眾多協議，但是限制只是用它們中被允許使用的一個子集。默認libcurl將會使用全部它支持的協議。參見 CURLOPT_REDIR_PROTOCOLS .
可用的協議選項為：CURLPROTO_HTTP、CURLPROTO_HTTPS、CURLPROTO_FTP、CURLPROTO_FTPS、CURLPROTO_SCP、CURLPROTO_SFTP、CURLPROTO_TELNET、CURLPROTO_LDAP、CURLPROTO_LDAPS、CURLPROTO_DICT、CURLPROTO_FILE、CURLPROTO_TFTP、CURLPROTO_ALL
對了，可定能得到返回值
『伍』 用java做一個httpClient 發送https 的get請求，需要證書驗證的那種，求大神指點一下！
你那個 SSLSocketFactory(ks) 是自己的類？
你有用過 KeyManager.init (...)? 和 TrustManager.init(...) ?
想要在連接建立過程上互動式的彈出確認對話框來的話需要我們自己提供一個 KeyManager 和 TrustManager 的實現類，這有點復雜，你可以看一個 Sun 的 X509KeyManager 是怎麼做的，默認地情況下它是從自動搜索匹配的 subject ，我們需要用自己提供的方式彈出確認的過程還不是全自動，另外一個賬戶可能有多個數字證書，比如支付寶我們就有多個簽發時間不一樣的數字證書，在連接建立時 IE 會提示我們選擇其中的一個來使用，銀行的 U 盾在安裝多張數字證書時也會提示我們選擇其中一個對應到你正在使用的銀行卡號的那張證書。
『陸』 HTTP協議中請求方法Get和Post的區別是什麼
在瀏覽器中輸入網址訪問資源都是通過GET方式;在FORM提交中，可以通過Method指定提交方式為GET或者POST，默認為GET提交。
HTTP 定義了與伺服器交互的不同方法，最常用的有4種，Put(增),Delete(刪)，Post(改),Get(查)，即增刪改查：
1)Get，
它用於獲取信息，注意，他只是獲取、查詢數據，也就是說它不會修改伺服器上的數據，從這點來講，它是數據安全的，而稍後會提到的Post它是可以修改數據的，所以這也是兩者差別之一了。
2)
Post，它是可以向伺服器發送修改請求，從而修改伺服器的，比方說，我們要在論壇上回貼、在博客上評論，這就要用到Post了，當然它也是可以僅僅獲取數據的。
3)Delete 刪除數據。可以通過Get/Post來實現。
4)Put，增加、放置數據，可以通過Get/Post來實現。
根據HTTP規范，GET用於信息獲取，而且應該是安全的和冪等的 。
1.所謂安全的意味著該操作用於獲取信息而非修改信息。換句話說，GET請求一般不應產生副作用。就是說，僅僅是獲取資源信息，就像資料庫查詢一樣，不會修改，增加數據，不會影響資源的狀態。(注意：這里安全的含義僅僅是指是非修改信息。)
根據HTTP規范，POST表示可能修改變伺服器上的資源的請求
。繼續引用上面的例子：還是新聞以網站為例，讀者對新聞發表自己的評論應該通過POST實現，因為在評論提交後站點的資源已經不同了，或者說資源被修改了。
HTTP請求：在HTTP請求中，第一行必須是一個請求行(request
line)，用來說明請求類型、要訪問的資源以及使用的HTTP版本。緊接著是一個首部(header)小節，用來說明伺服器要使用的附加信息。在首部之後是一個空行，再此之後可以添加任意的其他數據[稱之為主體(body)]。
兩種提交方式的區別：
(1)GET提交，請求的數據會附在URL之後(就是把數據放置在HTTP協議頭中)，以?分割URL和傳輸數據，多個參數用&連接。如果數據是英文字母/數字，原樣發送，如果是空格，轉換為+，如果是中文/其他字元，則直接把字元串用BASE64加密，得出如：
%E4%BD%A0%E5%A5%BD，其中%XX中的XX為該符號以16進製表示的ASCII。
POST提交：把提交的數據放置在是HTTP包的包體中。上文示例中紅色字體標明的就是實際的傳輸數據
因此，GET提交的數據會在地址欄中顯示出來，而POST提交，地址欄不會改變
(2)傳輸數據的大小：首先聲明：HTTP協議沒有對傳輸的數據大小進行限制，HTTP協議規范也沒有對URL長度進行限制。
而在實際開發中存在的限制主要有：
GET:特定瀏覽器和伺服器對URL長度有限制，例如IE對URL長度的限制是2083位元組(2K+35)。對於其他瀏覽器，如Netscape、FireFox等，理論上沒有長度限制，其限製取決於操作系統的支持。
因此對於GET提交時，傳輸數據就會受到URL長度的限制。
POST:由於不是通過URL傳值，理論上數據不受限。但實際各個WEB伺服器會規定對post提交數據大小進行限制，Apache、IIS6都有各自的配置。
『柒』 https會對GET或POST參數加密嗎
HTTPS實際是SSL over HTTP, 該協議通過SSL在發送方把原始數據進行加密，在接收方解 密，因此，所傳送的數據不容易被網路黑客截獲和破解。本文介紹HTTPS的三種實現方法 。 方法一 靜態超鏈接 這是目前網站中使用得較多的方法，也最簡單。在要求使...
『捌』 get請求不安全,那為啥不棄用get，直接用post 不就好了
POST會進行兩次連接，一次發送header一次發送body，而GET只有一次，網路耗時相比之下就低，所以在請求響應並不是很隱私的信息或者重要信息的時候，最好使用GET
『玖』 如何判斷一個post請求使用了ssl協議
HTTPS實際是SSL over HTTP, 該協議通過SSL在發送方把原始數據進行加密，在接收方解 密，因此，所傳送的數據不容易被網路黑客截獲和破解。本文介紹HTTPS的三種實現方法 。 方法一 靜態超鏈接 這是目前網站中使用得較多的方法，也最簡單。