http請求/響應包格式

標籤：安全   設定   accept   zh-cn   apach   內容   tool   windows   str   

一、什麼是http協議?

轉載：http://blog.csdn.net/daijin888888/article/details/51025634

        由w3c制訂的一種網路應用程式層協議，定義了瀏覽器與web伺服器之間通訊的過程以及通訊時所使用的資料格式。
        1)通訊的過程
            step1,瀏覽器建立與web伺服器之間的串連
            step2,瀏覽器將請求資料打包(產生請求資料包)並發送給web伺服器。
            step3,web伺服器將處理結果打包(產生響應資料包)並發送給瀏覽器。
            step4,web伺服器關閉串連。
        如果瀏覽器要再發請求，需要重建立立新的串連。
        特點：　一次請求，一次串連。
        優點：    web伺服器可以利用有限的串連為儘可能多的用戶端(瀏覽器)服務。
        2)資料格式

            a,請求資料包

                如：

[plain] view plain copy 

1. POST /web02/hello HTTP/1.1  
2.   
3. Host: localhost:8080  
4. User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20100101 Firefox/15.0.1  
5. Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8  
6. Accept-Language: zh-cn,zh;q=0.8,en-us;q=0.5,en;q=0.3  
7. Accept-Encoding: gzip, deflate  
8. Connection: keep-alive  
9. Referer: http://localhost:8888/web02/hello_form.html  
10. Content-Type: application/x-www-form-urlencoded  
11. Content-Length: 16  

 

                請求行: 請求方式　請求資源路徑　協議類型和版本
                訊息頭:
                    訊息頭是一些索引值對，一般由w3c定義，瀏覽器與web伺服器之間都可以發送，表示特定的某種含義，比如，瀏覽器可以發送"user-agent"訊息頭，告訴web伺服器瀏覽器的類型和版本。
                實體內容:
                    只有當請求方式為post時才有值(請求參數)，如果請求方式為get，請求參數會添加到請求資源路徑的後面。

            b,響應資料包

                如：

 

[plain] view plain copy 

1. HTTP/1.1 200 OK  
2. Server: Apache-Coyote/1.1  
3. Content-Type: text/html;charset=utf-8  
4. Content-Length: 30  
5. Date: Thu, 05 Dec 2013 07:16:28 GMT  

 

                狀態行: 協議類型和版本　狀態代碼　狀態原因
                    b1,什麼是狀態代碼
                        是一個三位元字，由w3c定義，表示伺服器處理請求的狀態。
                    b2,常見的狀態代碼
                        200:  伺服器處理請求正常。
                        404:  伺服器依據請求路徑找不到對應的資源。
                        500:  系統錯誤，伺服器端的程式在運行過程當中出錯了。
                        405: 伺服器找不到可執行檔方法來處理請求。        
                訊息頭:
                     伺服器也可以發送一些訊息頭給瀏覽器，比如"content-type",告訴瀏覽器，伺服器返回的資料類型和編碼格式(字元集)。
                實體內容:
                    程式處理的結果,瀏覽器會將實體內容中的資料取出來，產生相應的頁面。

二、請求方式

        1)哪一些情況下，瀏覽器會發送get請求
            a,直接在瀏覽器地址欄輸入某個地址
            b,點選連結
            c,表單使用預設的提交方式
        2)get請求的特點
            a,會將請求參數放到請求資源路徑的後面，只能提交少量的資料(因為請求行最多隻能存放2k左右的資料)。
            b,會將請求參數顯示在瀏覽器地址欄，不安全(路由器會記錄請求地址)。
        3)哪一些情況下，瀏覽器會發送post請求
            設定了表單的method屬性值為post
        4)post請求的特點
            a,會將請求參數放到實體內容裡面，能提交大量的資料。
            b,不會將請求參數顯示在瀏覽器地址欄，相對安全(瀏覽器沒有加密)。
        不管是get還是post,都不會對請求參數加密，所以如果是敏感性資料，一般都需要加密處理（https）。

Http協議支援六種要求方法，即：
　　0，GET
　　1，HEAD
　　2，PUT
　　3，DELETE
　　4，POST
　　5，OPTIONS

　　6.trace

但其實我們大部分情況下只用到了GET和POST。如果想設計一個符合RESTful規範的web應用程式，則這六種方法都會用到。不過即使暫時不想涉及REST，瞭解這六種方法的本質仍然是很有作用的。大家將會發現，原來web也是很簡潔明了的。下面依次說明這六種方法。
　　0，GET：GET可以說是最常見的了，它本質就是發送一個請求來取得伺服器上的某一資源。資源通過一組HTTP頭和呈現資料（如HTML文本，或者圖片或者視頻等）返回給用戶端。GET請求中，永遠不會包含呈現資料。
　　1，HEAD：HEAD和GET本質是一樣的，區別在於HEAD不含有呈現資料，而僅僅是HTTP頭資訊。有的人可能覺得這個方法沒什麼用，其實不是這樣的。想象一個業務情景：欲判斷某個資源是否存在，我們通常使用GET，但這裡用HEAD則意義更加明確。
　　2，PUT：這個方法比較少見。HTML表單也不支援這個。本質上來講， PUT和POST極為相似，都是向伺服器發送資料，但它們之間有一個重要區別，PUT通常指定了資源的存放位置，而POST則沒有，POST的資料存放位置由伺服器自己決定。舉個例子：如一個用於提交博文的URL，/addBlog。如果用PUT，則提交的URL會是像這樣的”/addBlog/abc123”，其中abc123就是這個博文的地址。而如果用POST，則這個地址會在提交後由伺服器告知用戶端。目前大部分部落格都是這樣的。顯然，PUT和POST用途是不一樣的。具體用哪個還取決於當前的業務情境。
　　3，DELETE：刪除某一個資源。基本上這個也很少見，不過還是有一些地方比如amazon的S3雲端服務裡面就用的這個方法來刪除資源。
　　4，POST：向伺服器提交資料。這個方法用途廣泛，幾乎目前所有的提交操作都是靠這個完成。
　　5，OPTIONS：這個方法很有趣，但極少使用。它用於擷取當前URL所支援的方法。若請求成功，則它會在HTTP頭中包含一個名為“Allow”的頭，值是所支援的方法，如“GET, POST”。
　　其實還有一個TRACE方法，不過這個基本上不會用到，這裡就不介紹了。

 

http請求/響應包格式