HTTP個人總結（二）

今天主要總結兩塊內容，HTTP報文和URL資源。

首先總結URL和資源。

URL是什麼？
URL就是因特網資源的標準化名稱

URL的語法又是什麼？
大多數的URL語法都建立在下面由9個部分構成的通用格式上：
scheme://user:password@host:port/path/params?query>#flag
解釋如下：

方案——使用什麼協議。方案實際上就是規定如何訪問指定資源的標識符。它會告訴負責解析URL的應用程序應該使用什麼協議。方案組件必須以一個字符符號開始，由第一個“：”符號將其與URL的其餘部分分隔開來。

主機與端口：能夠提供哪臺機器裝載了資源，以及在那臺機器的什麼地方可以找到能對目標資源進行訪問的服務器。

用戶名和密碼：很多服務器都要求輸入用戶名和密碼纔會允許訪問用戶的訪問數據
比如在工作上使用ssh連接服務器如：ssh [email protected] 之後會讓你輸入密碼

路徑：說明了資源位於服務器的什麼地方，可以使用字符“/“將HTTP URL的路徑組件劃分成一些路徑段，每個路徑段都有自己的參數組件

參數：爲了嚮應用程序提供它們所需的輸入參數，以便正確地與服務器進行交互，URL中有一個參數組件。比如：
ftp://prep.ai.mit.edu/pub/gnu;type=d

在這個例子中，有一個參數type=d,參數名爲type，值爲d

查詢字符串:如：http://www.joes-hardware.com/inventory-check,cgi?item=12631
這個URL問號（？）右邊部分就是查詢組件，多查詢參數中間用&分隔

片段：比如一個帶有章節性的大型文本文檔，資源的URL會指向整個文本文檔，使用片段（flag）來表示一個資源內部的片段。HTTP服務器通常只處理整個對象，而不是對象的片段，客戶端不能講片段傳送給服務器，瀏覽器從服務器獲得整個資源之後，會根據片段來顯示你感興趣的那部分資源。

接下來講URL的快捷方式？

相對URL是URL的一種便捷縮略記法。基礎URL是作爲相對URL的參考點使用的，可以來自以下地方：
1.在資源中顯示提供。比如HTML文檔中可能包含一個基礎URL的HTML標記
2.封裝資源的基礎URL。沒有顯示指定的基礎URL，可以將它所屬資源的URL作爲基礎
3.沒有基礎URL，在某種情況下，沒有基礎URL。這通常意味着你有一個相對URL，但有時可能只是一個不完整或損壞了的URL

解析相對引用：

舉個例子：
1.路徑爲./hammers.html，基礎URL爲http://www .joes-hardware.com/tools.html
2.方案爲空，沿着圖表的左半邊向下處理，基礎基礎URL的方案
3.至少一個組件非空，一直處理到低端，繼承主機和端口組件
4.將來自相對URL的組件與我們繼承來的組件合併起來，得到新的絕對URL

自動擴展URL特性有兩種方式：
1.主機名擴展
2.歷史擴展

還有各種令人頭疼的符號？
URL是可移植性的，它要統一命名因特網上所有的資源，安全傳輸意味着URL的傳輸不能丟失信息，爲了避開這些問題，URL只能使用一些相對較小、通用的安全字母表中的字符，設計者們還希望URL是可讀的，因此，即使不可見，不可打印的字符能夠穿過郵件程序，從而成爲可移植的，也不能在URL中使用

URL字符集：URL的設計者將轉義序列集成了進去，通過轉義序列，就可以使用US-ASCII字符集的有限子集對任意自賦值或數據進行編碼了，這就實現了可移植性和完整性

編碼機制：爲了避開安全字符集表示法帶來的限制，通過一種轉義表示法來表示不安全的字符，這種轉義表示法包含一個百分號（%），後面跟着兩個表示字符ASCII碼的十六進制數
通常搜索引擎會出現這種，比如百度搜索某個中文內容，在URL上就會出現這種形式

字符限制：在URL中有幾個字符被保留起來，有着特殊的含義，有些字符不在定義的US-ASCII可打印字符集中。還有些字符會與某些因特網網關和協議產生混淆，因此不贊成使用如：

有時你使用一些不安全字符的時候並沒有發生什麼不好的事情，對某些傳輸協議來說，這並不是問題，但對應用程序開發人員來說，對非安全字符進行編碼仍然是明智的

關於方案：

下面總結關閉HTTP報文這塊內容。

什麼是報文流？
HTTP報文在HTTP應用程序之間發送的數據塊，流動形式：

那麼報文又是由哪幾個部分組成的？
1.由報文描述的起始行
2.包含屬性的首部塊
3.包含數據的主體部分

其中起始行和首部行是由分隔的ASCII文本，每行都以一個由兩個字符組成的行終止序列作爲結束，其中包括一個回車符（ASCII碼13）和一個換行符（ASCII碼10）。這個行終止序列可以寫做CRLF，儘管規範是這樣，但是穩健的應用程序也應該接受單個換行符作爲行的終止。
報文的主體是一個可選數據塊，可以包含文本和二進制數據，也可以爲空

報文的語法？
所有的HTTP報文分爲兩類：請求報文和響應報文。如：

請求報文格式：

響應報文格式：

下面對各部分簡要描述：
方法(method)：客戶端希望服務器對資源執行的動作，如GET、POST
請求URL（request-URL)：命名了所請求資源，或者URL路徑組件的完整URL
版本（version）：報文所使用的HTTP版本
狀態碼（status）：三位數字描述了請求過程中發生的情況
原因短語（reason-phrase）：數字狀態碼的可讀版本
首部（headers）：可以有零個或多個首部，每個首部都包含以key：value的形式，由一個空行（CRLF）結束，表示首部列表的結束和主體部分的開始
實體的主體部分（entity-body）:包含一個任意數組組成的數據塊
注意，一組HTTP首部總是應該以一個空行（單個CRLF）結束，甚至即使沒有首部和實體主體部分也應該如此，但是由於很多客戶端和服務器（錯誤的）省略了最後的CRLF，爲了兼容，我們都應該接受那些最後沒有CRLF的報文

起始行？
所有的HTTP報文都以一個起始行作爲開始，請求報文的起始行說明了要做些什麼，響應報文的起始行說明發生了什麼。
方法：HTTP規範中定義了一組常用的請求方法，描述了7種，有些方法的請求報文中有主體，有些則是無主體的要求

狀態碼：方法是用來告訴服務器做什麼事情的，狀態碼則用來告訴客戶端發生了什麼事情。

首部又有什麼？
首部分類以下幾種：
1.通用首部：既可以出現在請求報文中，也可以出現在響應報文中
2.請求首部：提供更多有關請求的信息
3.響應首部：提供更多關於響應的信息
4.實體首部：描述主體的長度和內容，或者資源本身
5.擴展首部：規範中沒有定義的新首部

首部延續行：將長首部行爲分爲多行可以提高可讀性，多出來的每行前面至少要有一個空格或者製表符。

方法的詳細介紹？
並不是每個服務器都實現了所有的方法，如果一臺服務器要與HTTP/1.1兼容，只需要實現GET和HEAD方法就行，並且有些方法如DELETE等方法會受限，可能不希望任何人都能夠操作資源，這些限制通常都是在服務器配置中設置的，因此會隨着站點和服務器的不同而有所不同。
GET方法：通常用於請求服務器發送某個資源，HTTP/1.1要求服務器實現此方法。

HEAD方法：與GET方法行爲類似，但是服務器在響應中只返回首部，不會返回實體的主體部分。使用HEAD可以在不獲取資源的情況下了解資源的情況，通過查看響應中的狀態碼，看看某個對象是否存在，通過查看首部，測試資源是否被修改。服務器開發者必須確保返回的首部與GET請求所返回的首部完全相同，並且跟GET一樣是HTTP/1.1必須實現的方法

PUT方法：與GET從服務器讀取文檔相反，PUT方法會向服務器寫入文檔。PUT方法的語義就是讓服務器用戶請求的主體部分創建一個由所請求的URL命名新的文檔，如果那個URL已經存在的話，就用這個主體替代它。

POST方法：通常用它來支持HTML的表單。如：

TRACE方法：客服端發起一個請求時可能要穿過防火牆、代理、網關或其他一些應用程序。每個中間節點都可能會修改原始的HTTP請求，TRACE方法允許客戶端在最終將請求發送給服務器，看看它變成了什麼樣子。

TRACE方法主要用於診斷，用於驗證請求是否如願穿過了請求/響應鏈。

OPTIONS方法：請求WEB服務器告知其支持的各種功能。

DELETE方法：所做的就是請服務器刪除請求URL所指定的資源，但是客戶端應用程序無法保證刪除操作一定會被執行。

擴展方法：HTTP被設計成字段可擴展的，這樣新的特性就不會使老的軟件失效了。擴展方法指的就是沒有在HTTP/1.1規範定義的方法。服務器會爲它所管理的資源實現一些服務。如WebDAV HTTP擴展

如果你定義了一個擴展方法，很可能大部分HTTP應用程序都無法理解，同樣你的應用程序也可能會遇到一些其他應用程序在用，而不理解的擴展方法。所以最好對擴展方法寬容一些，如果在不破壞端到端行爲的情況下將帶有未知方法的報文傳遞給下游服務器，代理會嘗試傳遞這些報文，否則會以501（無法實現）狀態碼迴應。最好按慣例：對所發送的內容要求嚴一點，對所接受的內容寬容一點

下面來講狀態碼：
100~199——信息性狀態碼：（不是太懂，暫不要求）