HTTP的簡單的解析
阿新 • • 發佈：2019-02-27
之前 命令 識別 digi 普通 標識符 緩存 3.2 版本
請求URI就是統一資源標識符，用來標識要請求的資源。
Request-URI = absoluteURI | abs_path
上面兩種請求URI方式可根據實際的請求方式選擇使用。
絕對URI（absoluteURI）格式只在代理（proxy）在產生請求時使用。代理的責任是將
請求向前推送，並將回應返回。如果請求是GET或HEAD方式，而且之前的回應被緩存，
如果代理忽略標題域的過期信息限制，它可能使用緩存中的消息。註意，代理可能將請求推
送至另外一個代理，也可將請求直接送至絕對URI中所指定的目的服務器。為了避免請求
循環，代理必須能夠識別它的所有服務器名，包括別名、本地變量及數字形式的IP地址。
下面是一個請求隊列的例子：
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.0
最普通的請求URI形式就是原始服務器或網關用來標識資源的方式。在這種方式下，
只有給出絕對路徑的URI才能被傳輸（見3.2.1節）。例如，如客戶端希望直接從原始服務
器上接收資源，它們將產生一個與主機"www.w3.org"80端口的TCP連接，並在完整請求之
後發送下面的命令：
GET /pub/WWW/TheProject.html HTTP/1.0
註意絕對路徑不可以為空，如果URI中沒有內容，也必須加上一個"/"（server root）。
請求URI以編碼字符串方式傳輸，有些字符可能在傳輸過程中被轉義（escape），如變
成“%HEXHEX”形式。具體這方面內容請參見RFC1738[4]。原始服務器在正確解釋請求
之前必須對請求URI進行解碼。
回應（Response）
在接收、解釋請求消息後，服務器端返回HTTP回應消息。
Response = Simple-Response | Full-Response
Simple-Response = [ Entity-Body ]
Full-Response = Status-Line ; Section 6.1
*( General-Header ; Section 4.3
| Response-Header ; Section 6.2
| Entity-Header ) ; Section 7.1
CRLF
[ Entity-Body ] ; Section 7.2
當請求是HTTP/0.9的或者服務器端只支持HTTP/0.9時，只能以Simple-Response方式
回應。如果客戶端發送HTTP/1.0完整請求後，接收到的回應不是以狀態行（Status-Line）
開頭的，客戶端將其視為簡單回應，並相應對其進行分析。註意，簡單請求只包括實體主體，
它在服務器端關閉連接時終止。
6.1 狀態行（Status-Line）
完整回應消息的第一行就是狀態行，它依次由協議版本、數字形式的狀態代碼、及相應
的詞語文本組成，各元素間以空格（SP）分隔，除了結尾的CRLF外，不允許出現單獨的
CR或LF符。
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
狀態行總是以協議版本及狀態代碼開頭，如：
"HTTP/" 1*DIGIT "." 1*DIGIT SP 3DIGIT SP
（如，"HTTP/1.0 200"）。
這種表示方式並不足以區分完整請求和簡單請求。簡單回應可能允許這種表達式出現在
實體主體的開始部分，但會引起消息的誤解。因為大多數HTTP/0.9的服務器都只能回
應"text/html"類型，在這種情況下，不可能產生完整的回應。
HTTP
中文全稱為超文本傳輸協議是一種為分布式，合作式，多媒體信息系統服務，面向應用層的協議。它是一種通用的，不分狀態（stateless)的協議，除了諸如名稱服務和分布對象管理系統之類的超文本用途外，還可以通過擴展它的請求方式，錯誤代碼和報頭來完成許多任務。HTTP的一個特點是數據表示方式的典型性和可協商性允許獨立於傳輸數據而建立系統。
簡單地閱讀了HTTP/1.1的中文版原文，因為英文版不能理解，其中我印象最深的是它的請求應答機制，真正的體現寫這個協議的智慧，用並不太繁雜的規定，去定義一個十分復雜的協議，還包含後來的發展，其包容性都十分完備，兼容性是相比較其他同類協議的最大優點吧，對其一些進行了摘要：
請求URI就是統一資源標識符，用來標識要請求的資源。
Request-URI = absoluteURI | abs_path
上面兩種請求URI方式可根據實際的請求方式選擇使用。
絕對URI（absoluteURI）格式只在代理（proxy）在產生請求時使用。代理的責任是將
請求向前推送，並將回應返回。如果請求是GET或HEAD方式，而且之前的回應被緩存，
如果代理忽略標題域的過期信息限制，它可能使用緩存中的消息。註意，代理可能將請求推
送至另外一個代理，也可將請求直接送至絕對URI中所指定的目的服務器。為了避免請求
循環，代理必須能夠識別它的所有服務器名，包括別名、本地變量及數字形式的IP地址。
下面是一個請求隊列的例子：
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.0
最普通的請求URI形式就是原始服務器或網關用來標識資源的方式。在這種方式下，
只有給出絕對路徑的URI才能被傳輸（見3.2.1節）。例如，如客戶端希望直接從原始服務
器上接收資源，它們將產生一個與主機"www.w3.org"80端口的TCP連接，並在完整請求之
後發送下面的命令：
GET /pub/WWW/TheProject.html HTTP/1.0
註意絕對路徑不可以為空，如果URI中沒有內容，也必須加上一個"/"（server root）。
請求URI以編碼字符串方式傳輸，有些字符可能在傳輸過程中被轉義（escape），如變
成“%HEXHEX”形式。具體這方面內容請參見RFC1738[4]。原始服務器在正確解釋請求
之前必須對請求URI進行解碼。
回應（Response）
在接收、解釋請求消息後，服務器端返回HTTP回應消息。
Response = Simple-Response | Full-Response
Simple-Response = [ Entity-Body ]
Full-Response = Status-Line ; Section 6.1
*( General-Header ; Section 4.3
| Response-Header ; Section 6.2
| Entity-Header ) ; Section 7.1
CRLF
[ Entity-Body ] ; Section 7.2
當請求是HTTP/0.9的或者服務器端只支持HTTP/0.9時，只能以Simple-Response方式
回應。如果客戶端發送HTTP/1.0完整請求後，接收到的回應不是以狀態行（Status-Line）
開頭的，客戶端將其視為簡單回應，並相應對其進行分析。註意，簡單請求只包括實體主體，
它在服務器端關閉連接時終止。
6.1 狀態行（Status-Line）
完整回應消息的第一行就是狀態行，它依次由協議版本、數字形式的狀態代碼、及相應
的詞語文本組成，各元素間以空格（SP）分隔，除了結尾的CRLF外，不允許出現單獨的
CR或LF符。
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
狀態行總是以協議版本及狀態代碼開頭，如：
"HTTP/" 1*DIGIT "." 1*DIGIT SP 3DIGIT SP
（如，"HTTP/1.0 200"）。
這種表示方式並不足以區分完整請求和簡單請求。簡單回應可能允許這種表達式出現在
實體主體的開始部分，但會引起消息的誤解。因為大多數HTTP/0.9的服務器都只能回
應"text/html"類型，在這種情況下，不可能產生完整的回應。
HTTP的簡單的解析