HTTP基礎：URL格式、 HTTP請求、響應、消息（轉載）

HTTP URL

　　格式：

　　http://host[:port][abs_path]

　　其中http表示要經過HTTP協議來定位網絡資源。

　　host表示合法的Internet主機域名或IP地址（以點分十進制格式表示）；

　　port用於指定一個端口號，擁有被請求資源的服務器主機監聽該端口的TCP鏈接。

　　若是port是空，則使用缺省的端口80。當服務器的端口不是80的時候，須要顯式指定端口號。

　　abs_path指定請求資源的URI(Uniform Resource Identifier，統一資源定位符)，若是URL中沒有給出abs_path，那麼當它做爲請求URI時，必須以「/」的形式給出。一般這個工做瀏覽器就幫咱們完成了。

 

　　瀏覽器與服務器鏈接的通常過程：

　　（以sohu網站爲例）：

 

                         

URL與URI

　　URI純粹是一個符號結構，用於指定構成Web資源的字符串的各個不一樣部分。

　　URL是一種特殊類型的URI，它包含了用於查找某個資源的足夠的信息。

　　其餘的URI，例如:mailto:zhanglong217@yahoo.com.cn，則不屬於URL，由於它裏面不存在根據該標識符來查找的任何數據。這種URI稱爲URN(通用資源名)。

 

HTTP請求

　　客戶端經過發送HTTP請求向服務器請求對資源的訪問。

　　HTTP請求由三部分組成，分別是：請求行，消息報頭，請求正文。

　　請求行以一個方法符號開頭，後面跟着請求URI和協議的版本，以CRLF做爲結尾。

　　請求行以空格分隔。除了做爲結尾的CRLF外，不容許出現單獨的CR或LF字符，格式以下：

　　Method Request-URI HTTP-Version CRLF

　　Method表示請求的方法，Request-URI是一個統一資源標識符，標識了要請求的資源，HTTP-Version表示請求的HTTP協議版本，CRLF表示回車換行。

 

　　例如：

　　GET /test.html HTTP/1.1 (CRLF)

 

HTTP請求方法

 

GET方法

　　GET方法用於獲取由Request-URI所標識的資源的信息，常見形式是：

　　GET Request-URI HTTP/1.1

　　當咱們經過在瀏覽器的地址欄中直接輸入網址的方式去訪問網頁的時候，瀏覽器採用的就是GET方法向服務器獲取資源。

 

    最多見的一種請求方式，當客戶端要從服務器中讀取文檔時，當點擊網頁上的連接或者經過在瀏覽器的地址欄輸入網址來瀏覽網頁的，使用的都是GET方式。GET方法要求服務器將URL定位的資源放在響應報文的數據部分，回送給客戶端。使用GET方法時，請求參數和對應的值附加在URL後面，利用一個問號（「?」）表明URL的結尾與請求參數的開始，傳遞參數長度受限制。例如，/index.jsp?id=100&op=bind,這樣經過GET方式傳遞的數據直接表示在地址中，因此咱們能夠把請求結果以連接的形式發送給好友。以用google搜索domety爲例，Request格式以下：

GET /search?hl=zh-CN&source=hp&q=domety&aq=f&oq= HTTP/1.1  
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, 
application/msword, application/x-silverlight, application/x-shockwave-flash, */*  
Referer: <a href="http://www.google.cn/">http://www.google.cn/</a>  
Accept-Language: zh-cn  
Accept-Encoding: gzip, deflate  
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; TheWorld)  
Host: <a href="http://www.google.cn">www.google.cn</a>  
Connection: Keep-Alive  
Cookie: PREF=ID=80a06da87be9ae3c:U=f7167333e2c3b714:NW=1:TM=1261551909:LM=1261551917:S=ybYcq2wpfefs4V9g; 
NID=31=ojj8d-IygaEtSxLgaJmqSjVhCspkviJrB6omjamNrSm8lZhKy_yMfO2M4QMRKcH1g0iQv9u-2hfBW7bUFwVh7pGaRUb0RnHcJU37y-
FxlRugatx63JLv7CWMD6UB_O_r  

    能夠看到，GET方式的請求通常不包含」請求內容」部分，請求數據以地址的形式表如今請求行。地址連接以下：

<a href="http://www.google.cn/search?hl=zh-CN&source=hp&q=domety&aq=f&oq=">http://www.google.cn/search?hl=zh-CN&source=hp
&q=domety&aq=f&oq=</a> 

    地址中」?」以後的部分就是經過GET發送的請求數據，咱們能夠在地址欄中清楚的看到，各個數據之間用」&」符號隔開。顯然，這種方式不適合傳送私密數據。另外，因爲不一樣的瀏覽器對地址的字符限制也有所不一樣，通常最多隻能識別1024個字符，因此若是須要傳送大量數據的時候，也不適合使用GET方式。

 

POST方法

　　POST方法用於想服務器發送請求，這點和GET方法沒有區別。可是POST方法要求服務器接收附在請求後面的數據。

　　POST方法在表單提交的時候用的最多。

　　採用POST方法提交表單的例子

　　POST /login.jsp HTTP/1.1 (CRLF)

　　Accept: image/gif (CRLF) (…)

　　Host: www.sample.com (CRLF) (…)

　　…

　　Cache-Control: no-cache (CRLF)

　　(CRLF)

　　username=hello&password=123456

　　當咱們在HTML中提交表單時，瀏覽器會根據你的提交方法是get仍是post，採用相應的在HTTP協議中的GET或POST方法，向服務器發出請求。

　　注意，在HTML文檔中，書寫get和post，不區分大小寫，但HTTP協議中的GET和POST只能是大寫形式。

    對於上面提到的不適合使用GET方式的狀況，能夠考慮使用POST方式，由於使用POST方法能夠容許客戶端給服務器提供信息較多。POST方法將請求參數封裝在HTTP請求數據中，以名稱/值的形式出現，能夠傳輸大量數據，這樣POST方式對傳送的數據大小沒有限制，並且也不會顯示在URL中。還以上面的搜索domety爲例，若是使用POST方式的話，格式以下：

POST /search HTTP/1.1  
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, 
application/msword, application/x-silverlight, application/x-shockwave-flash, */*  
Referer: <a href="http://www.google.cn/">http://www.google.cn/</a>  
Accept-Language: zh-cn  
Accept-Encoding: gzip, deflate  
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; TheWorld)  
Host: <a href="http://www.google.cn">www.google.cn</a>  
Connection: Keep-Alive  
Cookie: PREF=ID=80a06da87be9ae3c:U=f7167333e2c3b714:NW=1:TM=1261551909:LM=1261551917:S=ybYcq2wpfefs4V9g; 
NID=31=ojj8d-IygaEtSxLgaJmqSjVhCspkviJrB6omjamNrSm8lZhKy_yMfO2M4QMRKcH1g0iQv9u-2hfBW7bUFwVh7pGaRUb0RnHcJU37y-
FxlRugatx63JLv7CWMD6UB_O_r  

hl=zh-CN&source=hp&q=domety  

    能夠看到，POST方式請求行中不包含數據字符串，這些數據保存在」請求內容」部分，各數據之間也是使用」&」符號隔開。POST方式大多用於頁面的表單中。由於POST也能完成GET的功能，所以多數人在設計表單的時候一概都使用POST方式，其實這是一個誤區。GET方式也有本身的特色和優點，咱們應該根據不一樣的狀況來選擇是使用GET仍是使用POST。

 

HEAD方法

　　HEAD方法與GET方法幾乎是同樣的，它們的區別在於HEAD方法只是請求消息報頭，而不是完整的內容。

　　對於HEAD請求的迴應部分來講，它的HTTP頭部中包含的信息與經過GET請求所獲得的信息是相同的。

　　利用這個方法，沒必要傳輸整個資源的內容，就能夠獲得Request-URI所標識的資源的信息。

　　這個方法一般用於測試超連接的有效性，是否能夠訪問，以及最近是否更新等。

 

HTTP響應

　　在接收和解釋請求消息後，服務器會返回一個HTTP響應消息。

　　與HTTP請求相似，HTTP響應也是由三個部分組成，分別是：狀態行，消息報頭，相應正文。

　　狀態行由協議版本，數字形式的狀態代碼，相應的狀態描述組成，各元素之間以空格分隔，除告終尾的CRLF(回車換行)序列外，不容許出現CR或LF字符。格式以下：

　　HTTP-Version Status-Code Reason-Phrase CRLF

　　HTTP-Version表示服務器HTTP協議的版本，Status-Code表示服務器發回的響應代碼，Reason-Phrase表示狀態代碼的文本描述，CRLF表示回車換行。

　　例如：

　　HTTP/1.1 200 OK (CRLF)

 

HTTP響應——狀態代碼與狀態描述

　　狀態代碼由三位數字組成，表示請求是否被理解或被知足，狀態描述給出了關於狀態代碼的簡短文本描述。

　　狀態代碼的第一個數字定義了響應的類別，後面兩個數字沒有具體的分類。

 

1xx：指示信息——表示請求已經接受，繼續處理 2xx：成功——表示請求已經被成功接收、理解、接受。 3xx：重定向——要完成請求必須進行更進一步的操做 4xx：客戶端錯誤——請求有語法錯誤或請求沒法實現 5xx：服務器端錯誤——服務器未能實現合法的請求。 常見狀態代碼、狀態描述、說明： 200 OK //客戶端請求成功 400 Bad Request //客戶端請求有語法錯誤，不能被服務器所理解 401 Unauthorized //請求未經受權，這個狀態代碼必須和WWW-Authenticate報頭域一塊兒使用 403 Forbidden //服務器收到請求，可是拒絕提供服務 404 Not Found //請求資源不存在，eg：輸入了錯誤的URL 500 Internal Server Error //服務器發生不可預期的錯誤 503 Server Unavailable //服務器當前不能處理客戶端的請求，一段時間後可能恢復正常

　　狀態行由協議版本，數字形式的狀態代碼，相應的狀態描述組成，各元素之間以空格分隔，除告終尾的CRLF（回車換行）序列外，不容許出現CR或LF字符。格式以下：

　　HTTP-Version Status-Code Reason-Phrase CRLF

 

HTTP消息

　　HTTP消息由客戶端到服務器的請求和服務器到客戶端的響應組成。

　　請求消息和響應消息都是由開始行，消息報頭（可選），空行（只有CRLF的行），消息正文（可選）組成。

　　對於請求消息，開始行就是請求行，對於相應消息，開始行就是狀態行。

　　實驗工具：Telnet

　　HTTP協議與TELNET協議都是基於TCP協議。

 

轉載地址：http://www.cnblogs.com/mengdd/archive/2013/05/26/3099776.html