網絡基礎知識(二) HTTP
黑髮不知勤學早，白首方悔讀書遲。
內容參考：https://www.runoob.com/http/http-content-type.html
HTTP協議是Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫,是用於從萬維網（WWW:World Wide Web ）服務器傳輸超文本到本地瀏覽器的傳送協議。。
HTTP是一個基於TCP/IP通信協議來傳遞數據（HTML 文件, 圖片文件, 查詢結果等）。
Http工作原理
HTTP協議工作於客戶端-服務端架構上。瀏覽器作爲HTTP客戶端通過URL向HTTP服務端即WEB服務器發送所有請求。
Web服務器有：Apache服務器，IIS服務器（Internet Information Services）等。
Web服務器根據接收到的請求後，向客戶端發送響應信息。
HTTP默認端口號爲80，但是你也可以改爲8080或者其他端口。
HTTP三點注意事項：
• HTTP是無連接：無連接的含義是限制每次連接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開連接。採用這種方式可以節省傳輸時間。
• HTTP是媒體獨立的：這意味着，只要客戶端和服務器知道如何處理的數據內容，任何類型的數據都可以通過HTTP發送。客戶端以及服務器指定使用適合的MIME-type內容類型。（詳見下面介紹：HTTP content-Type ）
• HTTP是無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味着如果後續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。另一方面，在服務器不需要先前信息時它的應答就較快。
CGI(Common Gateway Interface) 是 HTTP
服務器與你的或其它機器上的程序進行“交談”的一種工具，其程序須運行在網絡服務器上。 絕大多數的 CGI
程序被用來解釋處理來自表單的輸入信息，並在服務器產生相應的處理，或將相應的信息反饋給瀏覽器。CGI 程序使網頁具有交互功能。瀏覽器顯示的內容都有 HTML、XML、GIF、Flash 等，瀏覽器是通過 MIME Type 區分它們，決定用什麼內容什麼形式來顯示。
註釋：MIME Type 是該資源的媒體類型，MIME Type 不是個人指定的，是經過互聯網（IETF）組織協商，以
RFC（是一系列以編號排定的文件，幾乎所有的互聯網標準都有收錄在其中） 的形式作爲建議的標準發佈在網上的，大多數的 Web
服務器和用戶代理都會支持這個規範 (順便說一句，Email 附件的類型也是通過 MIME Type 指定的)。 媒體類型通常通過 HTTP
協議，由 Web 服務器告知瀏覽器的，更準確地說，是通過 Content-Type
來表示的。例如：Content-Type：text/HTML。 通常只有一些卓哉互聯網上獲得廣泛應用的格式纔會獲得一個 MIME
Type，如果是某個客戶端自己定義的格式，一般只能以 application/x- 開頭。
HTTP 消息結構
HTTP是基於客戶端/服務端（C/S）的架構模型，通過一個可靠的鏈接來交換信息，是一個無狀態的請求/響應協議。
一個HTTP"客戶端"是一個應用程序（Web瀏覽器或其他任何客戶端），通過連接到服務器達到向服務器發送一個或多個HTTP的請求的目的。
一個HTTP"服務器"同樣也是一個應用程序（通常是一個Web服務，如Apache Web服務器或IIS服務器等），通過接收客戶端的請求並向客戶端發送HTTP響應數據。
HTTP使用統一資源標識符（Uniform Resource Identifiers, URI）來傳輸數據和建立連接。
一旦建立連接後，數據消息就通過類似Internet郵件所使用的格式[RFC5322]和多用途Internet郵件擴展（MIME）[RFC2045]來傳送。
客戶端請求消息
一個HTTP請求報文由請求行（request line）、請求頭（header）、空行和請求數據4個部分組成，下圖給出了請求報文的一般格式。
請求行
請求行由請求方法字段、URL字段和HTTP協議版本字段3個字段組成，它們用空格分隔。例如，GET /index.html HTTP/1.1。
根據HTTP標準，HTTP請求可以使用多種請求方法。
• HTTP1.0定義了三種請求方法： GET, POST 和 HEAD方法。
• HTTP1.1新增了五種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。
HTTP 協議的 8 種請求類型介紹
HTTP 協議中共定義了八種方法或者叫“動作”來表明對 Request-URI 指定的資源的不同操作方式，具體介紹如下：
- OPTIONS：返回服務器針對特定資源所支持的HTTP請求方法。也可以利用向Web服務器發送’*'的請求來測試服務器的功能性。
- HEAD：向服務器索要與GET請求相一致的響應，只不過響應體將不會被返回。這一方法可以在不必傳輸整個響應內容的情況下，就可以獲取包含在響應消息頭中的元信息。
- GET：向特定的資源發出請求。
- POST：向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會導致新的資源的創建和/或已有資源的修改。
- PUT：向指定資源位置上傳其最新內容。
- DELETE：請求服務器刪除 Request-URI 所標識的資源。
- TRACE：回顯服務器收到的請求，主要用於測試或診斷。
- CONNECT：HTTP/1.1 協議中預留給能夠將連接改爲管道方式的代理服務器。
雖然 HTTP 的請求方式有 8 種，但是我們在實際應用中常用的也就是 get 和 post，其他請求方式也都可以通過這兩種方式間接的來實現。
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方式。
2).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_rhl=zh-CN&source=hp&q=domety
可以看到，POST方式請求行中不包含數據字符串，這些數據保存在”請求內容”部分，各數據之間也是使用”&”符號隔開。POST方式大多用於頁面的表單中。因爲POST也能完成GET的功能，因此多數人在設計表單的時候一律都使用POST方式，其實這是一個誤區。GET方式也有自己的特點和優勢，我們應該根據不同的情況來選擇是使用GET還是使用POST。
3).HEAD
HEAD就像GET，只不過服務端接受到HEAD請求後只返回響應頭，而不會發送響應內容。當我們只需要查看某個頁面的狀態的時候，使用HEAD是非常高效的，因爲在傳輸的過程中省去了頁面內容。
請求頭
請求頭部由關鍵字/值對組成，每行一對，關鍵字和值用英文冒號“:”分隔。請求頭部通知服務器有關於客戶端請求的信息，典型的請求頭有：
• User-Agent：產生請求的瀏覽器類型。
• Accept：客戶端可識別的內容類型列表。
• Host：請求的主機名，允許多個域名同處一個IP地址，即虛擬主機。
空行
最後一個請求頭之後是一個空行，發送回車符和換行符，通知服務器以下不再有請求頭。
請求數據
請求數據不在GET方法中使用，而是在POST方法中使用。POST方法適用於需要客戶填寫表單的場合。與請求數據相關的最常使用的請求頭是Content-Type和Content-Length。
示例
1).GET
//請求首行
GET /hello/index.jsp HTTP/1.1
//請求頭信息，因爲GET請求沒有正文
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-cn,zh;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: GB2312,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Cookie: JSESSIONID=369766FDF6220F7803433C0B2DE36D98
//空行
//因爲GET沒有正文，所以下面爲空
2).POST
// 請求首行
POST /hello/index.jsp HTTP/1.1
//請求頭信息
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-cn,zh;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: GB2312,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://localhost/hello/index.jsp
Cookie: JSESSIONID=369766FDF6220F7803433C0B2DE36D98
Content-Type: application/x-www-form-urlencoded
Content-Length: 14
// 這裏是空行
//POST有請求正文
username=hello
服務器響應消息
HTTP響應也由四個部分組成，分別是：狀態行、響應頭、空行、響應正文。
正如你所見，在響應中唯一真正的區別在於第一行中用狀態信息代替了請求信息。狀態行（status line）通過提供一個狀態碼來說明所請求的資源情況。
狀態行格式如下：
HTTP-Version Status-Code Reason-Phrase CRLF
其中，HTTP-Version表示服務器HTTP協議的版本；
Status-Code表示服務器發回的響應狀態代碼；
Reason-Phrase表示狀態代碼的文本描述。
HTTP狀態碼
當瀏覽者訪問一個網頁時，瀏覽者的瀏覽器會向網頁所在服務器發出請求。當瀏覽器接收並顯示網頁前，此網頁所在的服務器會返回一個包含HTTP狀態碼的信息頭（server header）用以響應瀏覽器的請求。
HTTP狀態碼的英文爲HTTP Status Code。狀態代碼由三個十進制數字組成，第一個十進制數字定義了狀態碼的類型，後兩個數字沒有分類的作用，且有五種可能取值。
• 1xx：指示信息–表示請求已接收，繼續處理。
• 2xx：成功–表示請求已被成功接收、理解、接受。
• 3xx：重定向–要完成請求必須進行更進一步的操作。
• 4xx：客戶端錯誤–請求有語法錯誤或請求無法實現。
• 5xx：服務器端錯誤–服務器未能實現合法的請求。
常見狀態代碼、狀態描述的說明如下
• 200 OK：客戶端請求成功。
• 400 Bad Request：客戶端請求有語法錯誤，不能被服務器所理解。
• 401 Unauthorized：請求未經授權，這個狀態代碼必須和WWW-Authenticate報頭域一起使用。
• 403Forbidden：服務器收到請求，但是拒絕提供服務。
• 404 Not Found：請求資源不存在，舉個例子：輸入了錯誤的URL。
• 500 Internal Server Error：服務器發生不可預期的錯誤。
• 503 ServerUnavailable：服務器當前不能處理客戶端的請求，一段時間後可能恢復正常，舉個例子：HTTP/1.1 200 OK（CRLF）。
HTTP狀態碼列表:
| 狀態碼 | 狀態碼英文名稱 | 中文描述 |
|---|---|---|
| 100 | Continue | 繼續，客戶端應繼續其請求 |
| 101 | Switching Protocols | 切換協議。服務器根據客戶端的請求切換協議。只能切換到更高級的協議，例如，切換到HTTP的新版本協議 |
| 200 | OK | 請求成功。一般用於GET與POST請求 |
| 201 | Created | 已創建。成功請求並創建了新的資源 |
| 202 | Accepted | 已接受。已經接受請求，但未處理完成 |
| 203 | Non-Authoritative Information | 非授權信息。請求成功。但返回的meta信息不在原始的服務器，而是一個副本 |
| 204 | No Content | 無內容。服務器成功處理，但未返回內容。在未更新網頁的情況下，可確保瀏覽器繼續顯示當前文檔 |
| 205 | Reset Content | 重置內容。服務器處理成功，用戶終端（例如：瀏覽器）應重置文檔視圖。可通過此返回碼清除瀏覽器的表單域 |
| 206 | Partial Content | 部分內容。服務器成功處理了部分GET請求 |
| 300 | Multiple Choices | 多種選擇。請求的資源可包括多個位置，相應可返回一個資源特徵與地址的列表用於用戶終端（例如：瀏覽器）選擇 |
| 301 | Moved Permanently | 永久移動。請求的資源已被永久的移動到新URI，返回信息會包括新的URI，瀏覽器會自動定向到新URI。今後任何新的請求都應使用新的URI代替 |
| 302 | Found | 臨時移動。與301類似。但資源只是臨時被移動。客戶端應繼續使用原有URI |
| 303 | See Other | 查看其它地址。與301類似。使用GET和POST請求查看 |
| 304 | Not Modified | 未修改。所請求的資源未修改，服務器返回此狀態碼時，不會返回任何資源。客戶端通常會緩存訪問過的資源，通過提供一個頭信息指出客戶端希望只返回在指定日期之後修改的資源 |
| 305 | Use Proxy | 使用代理。所請求的資源必須通過代理訪問 |
| 306 | Unused | 已經被廢棄的HTTP狀態碼 |
| 307 | Temporary Redirect | 臨時重定向。與302類似。使用GET請求重定向 |
| 400 | Bad Request | 客戶端請求的語法錯誤，服務器無法理解 |
| 401 | Unauthorized | 請求要求用戶的身份認證 |
| 402 | Payment Required | 保留，將來使用 |
| 403 | Forbidden | 服務器理解請求客戶端的請求，但是拒絕執行此請求 |
| 404 | Not Found | 服務器無法根據客戶端的請求找到資源（網頁）。通過此代碼，網站設計人員可設置"您所請求的資源無法找到"的個性頁面 |
| 405 | Method Not Allowed | 客戶端請求中的方法被禁止 |
| 406 | Not Acceptable | 服務器無法根據客戶端請求的內容特性完成請求 |
| 407 | Proxy Authentication Required | 請求要求代理的身份認證，與401類似，但請求者應當使用代理進行授權 |
| 408 | Request Time-out | 服務器等待客戶端發送的請求時間過長，超時 |
| 409 | Conflict | 服務器完成客戶端的 PUT 請求時可能返回此代碼，服務器處理請求時發生了衝突 |
| 410 | Gone | 客戶端請求的資源已經不存在。410不同於404，如果資源以前有現在被永久刪除了可使用410代碼，網站設計人員可通過301代碼指定資源的新位置 |
| 411 | Length Required | 服務器無法處理客戶端發送的不帶Content-Length的請求信息 |
| 412 | Precondition Failed | 客戶端請求信息的先決條件錯誤 |
| 413 | Request Entity Too Large | 由於請求的實體過大，服務器無法處理，因此拒絕請求。爲防止客戶端的連續請求，服務器可能會關閉連接。如果只是服務器暫時無法處理，則會包含一個Retry-After的響應信息 |
| 414 | Request-URI Too Large | 請求的URI過長（URI通常爲網址），服務器無法處理 |
| 415 | Unsupported Media Type | 服務器無法處理請求附帶的媒體格式 |
| 416 | Requested range not satisfiable | 客戶端請求的範圍無效 |
| 417 | Expectation Failed | 服務器無法滿足Expect的請求頭信息 |
| 500 | Internal Server Error | 服務器內部錯誤，無法完成請求 |
| 501 | Not Implemented | 服務器不支持請求的功能，無法完成請求 |
| 502 | Bad Gateway | 作爲網關或者代理工作的服務器嘗試執行請求時，從遠程服務 |
| 503 | Service Unavailable | 由於超載或系統維護，服務器暫時的無法處理客戶端的請求。 |
| 504 | Gateway Time-out | 充當網關或代理的服務器，未及時從遠端服務器獲取請求 |
| 505 | HTTP Version not supported | 服務器不支持請求的HTTP協議的版本，無法完成處理 |
HTTP響應頭
| 應答頭 | 說明 |
|---|---|
| Allow | 服務器支持哪些請求方法（如GET、POST等）。 |
| Content-Encoding | 文檔的編碼（Encode）方法。只有在解碼之後纔可以得到Content-Type頭指定的內容類型。利用gzip壓縮文檔能夠顯著地減少HTML文檔的下載時間。Java的GZIPOutputStream可以很方便地進行gzip壓縮，但只有Unix上的Netscape和Windows上的IE 4、IE 5才支持它。因此，Servlet應該通過查看Accept-Encoding頭（即request.getHeader(“Accept-Encoding”)）檢查瀏覽器是否支持gzip，爲支持gzip的瀏覽器返回經gzip壓縮的HTML頁面，爲其他瀏覽器返回普通頁面。 |
| Content-Length | 表示內容長度。只有當瀏覽器使用持久HTTP連接時才需要這個數據。如果你想要利用持久連接的優勢，可以把輸出文檔寫入 ByteArrayOutputStream，完成後查看其大小，然後把該值放入Content-Length頭，最後通過byteArrayStream.writeTo(response.getOutputStream()發送內容。 |
| Content-Type | 表示後面的文檔屬於什麼MIME類型。Servlet默認爲text/plain，但通常需要顯式地指定爲text/html。由於經常要設置Content-Type，因此HttpServletResponse提供了一個專用的方法setContentType。 |
| Date | 當前的GMT時間。你可以用setDateHeader來設置這個頭以避免轉換時間格式的麻煩。 |
| Expires | 應該在什麼時候認爲文檔已經過期，從而不再緩存它？ |
| Last-Modified | 文檔的最後改動時間。客戶可以通過If-Modified-Since請求頭提供一個日期，該請求將被視爲一個條件GET，只有改動時間遲於指定時間的文檔纔會返回，否則返回一個304（Not Modified）狀態。Last-Modified也可用setDateHeader方法來設置。 |
| Location | 表示客戶應當到哪裏去提取文檔。Location通常不是直接設置的，而是通過HttpServletResponse的sendRedirect方法，該方法同時設置狀態代碼爲302。 |
| Refresh | 表示瀏覽器應該在多少時間之後刷新文檔，以秒計。除了刷新當前文檔之外，你還可以通過setHeader(“Refresh”, “5; URL=http://host/path”)讓瀏覽器讀取指定的頁面. 注意這種功能通常是通過設置HTML頁面HEAD區的＜META HTTP-EQUIV=“Refresh” CONTENT=“5;URL=http://host/path"＞實現，這是因爲，自動刷新或重定向對於那些不能使用CGI或Servlet的HTML編寫者十分重要。但是，對於Servlet來說，直接設置Refresh頭更加方便。 注意Refresh的意義是"N秒之後刷新本頁面或訪問指定頁面”，而不是"每隔N秒刷新本頁面或訪問指定頁面"。因此，連續刷新要求每次都發送一個Refresh頭，而發送204狀態代碼則可以阻止瀏覽器繼續刷新，不管是使用Refresh頭還是＜META HTTP-EQUIV=“Refresh” …＞。 注意Refresh頭不屬於HTTP 1.1正式規範的一部分，而是一個擴展，但Netscape和IE都支持它。 |
| Server | 服務器名字。Servlet一般不設置這個值，而是由Web服務器自己設置。 |
| Set-Cookie | 設置和頁面關聯的Cookie。Servlet不應使用response.setHeader(“Set-Cookie”, …)，而是應使用HttpServletResponse提供的專用方法addCookie。參見下文有關Cookie設置的討論。 |
| WWW-Authenticate | 客戶應該在Authorization頭中提供什麼類型的授權信息？在包含401（Unauthorized）狀態行的應答中這個頭是必需的。例如，response.setHeader(“WWW-Authenticate”, “BASIC realm=＼“executives＼””)。 注意Servlet一般不進行這方面的處理，而是讓Web服務器的專門機制來控制受密碼保護頁面的訪問（例如.htaccess）。 |
HTTP content-Type
Content-Type，內容類型，一般是指網頁中存在的Content-Type，用於定義網絡文件的類型和網頁的編碼，決定瀏覽器將以什麼形式、什麼編碼讀取這個文件，這就是經常看到一些Asp網頁點擊的結果卻是下載到的一個文件或一張圖片的原因。
Content-Type 標頭告訴客戶端實際返回的內容的內容類型。
語法格式：
Content-Type: text/html; charset=utf-8 Content-Type:
multipart/form-data; boundary=something
常見的媒體格式類型如下：
• text/html ： HTML格式
• text/plain ：純文本格式
• text/xml ： XML格式
• image/gif ：gif圖片格式
• image/jpeg ：jpg圖片格式
• image/png：png圖片格式
以application開頭的媒體格式類型：
• application/xhtml+xml ：XHTML格式
• application/xml： XML數據格式
• application/atom+xml ：Atom XML聚合格式
• application/json： JSON數據格式
• application/pdf：pdf格式
• application/msword ： Word文檔格式
• application/octet-stream ： 二進制流數據（如常見的文件下載）
• application/x-www-form-urlencoded ： 中默認的encType，form表單數據被編碼爲key/value格式發送到服務器（表單默認的提交數據的格式）
另外一種常見的媒體格式是上傳文件之時使用的：
• multipart/form-data ： 需要在表單中進行文件上傳時，就需要使用該格式
實例
下面實例是一點典型的使用GET來傳遞數據的實例：
客戶端請求：
GET /hello.txt HTTP/1.1
User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Host: www.example.com
Accept-Language: en, mi
服務端響應:
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain
輸出結果：
Hello World! My payload includes a trailing CRLF.
關於HTTP請求GET和POST的區別
1.提交
GET提交，請求的數據會附在URL之後（就是把數據放置在HTTP協議頭＜request-line＞中），以?分割URL和傳輸數據，多個參數用&連接;例如：login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0 %E5%A5%BD。如果數據是英文字母/數字，原樣發送，如果是空格，轉換爲+，如果是中文/其他字符，則直接把字符串用BASE64加密，得出如： %E4%BD%A0%E5%A5%BD，其中％XX中的XX爲該符號以16進製表示的ASCII。
POST提交：把提交的數據放置在是HTTP包的包體＜request-body＞中。上文示例中紅色字體標明的就是實際的傳輸數據
因此，GET提交的數據會在地址欄中顯示出來，而POST提交，地址欄不會改變
2.傳輸數據的大小：
首先聲明,HTTP協議沒有對傳輸的數據大小進行限制，HTTP協議規範也沒有對URL長度進行限制。 而在實際開發中存在的限制主要有：
GET:特定瀏覽器和服務器對URL長度有限制，例如IE對URL長度的限制是2083字節(2K+35)。對於其他瀏覽器，如Netscape、FireFox等，理論上沒有長度限制，其限制取決於操作系統的支持。
因此對於GET提交時，傳輸數據就會受到URL長度的限制。
POST:由於不是通過URL傳值，理論上數據不受限。但實際各個WEB服務器會規定對post提交數據大小進行限制，Apache、IIS6都有各自的配置。
3.安全性：
POST的安全性要比GET的安全性高。注意：這裏所說的安全性和上面GET提到的“安全”不是同個概念。上面“安全”的含義僅僅是不作數據修改，而這裏安全的含義是真正的Security的含義，比如：通過GET提交數據，用戶名和密碼將明文出現在URL上，因爲(1)登錄頁面有可能被瀏覽器緩存， (2)其他人查看瀏覽器的歷史紀錄，那麼別人就可以拿到你的賬號和密碼了，