一、HTTP協議的URL
HTTP URL (URL是一種特殊類型的URI，包含了用於查找某個資源的足夠的信息)的格式如下：
http://host[":"port][abs_path]
http表示要通過HTTP協議來定位網絡資源；
host表示合法的Internet主機域名或者IP地址；
port指定一個端口號，爲空則使用缺省端口80；
abs_path指定請求資源的URI；
如果URL中沒有給出abs_path，那麼當它作爲請求URI時，
必須以“/”的形式給出，通常這個工作瀏覽器自動幫我們完成。
eg:
1、輸入：www.guet.edu.cn
瀏覽器自動轉換成：http://www.guet.edu.cn/
2、http:192.168.0.116:8080/index.jsp
二、 Http協議的內容
Request and Response messages use the generic message format of RFC 822 [9] for transferring
entities (the payload of the message). Both types of message consist of a start-line,
zero or more header fields (also known as "headers"),
an empty line (i.e., a line with nothing preceding the CRLF)
indicating the end of the header fields, and possibly a message-body.
generic-message = start-line
*(message-header CRLF)
CRLF
[ message-body ]
http協議請求和響應內容都由三部分組成，分別是：行(請求行和狀態行)、報頭(消息頭)、正文(消息體)
消息頭和消息體之間,用CRLF(回車和換行)隔開,表示報頭域的結束.
請求行以一個方法符號開頭，以空格分開，後面跟着請求的URI和協議的版本，
格式如下：Method Request-URI HTTP-Version CRLF
其中 Method表示請求方法；
Request-URI是一個統一資源標識符；
HTTP-Version表示請求的HTTP協議版本,當前使用1.1；
CRLF表示回車和換行（除了作爲結尾的CRLF外，不允許出現單獨的CR或LF字符）。
請求方法（所有方法全爲大寫）有多種，各個方法的解釋如下：
GET 請求獲取Request-URI所標識的資源
POST 在Request-URI所標識的資源後附加新的數據
HEAD 請求獲取由Request-URI所標識的資源的響應消息報頭
PUT 請求服務器存儲一個資源，並用Request-URI作爲其標識
DELETE 請求服務器刪除Request-URI所標識的資源
TRACE 請求服務器回送收到的請求信息，主要用於測試或診斷
CONNECT 保留將來使用
OPTIONS 請求查詢服務器的性能，或者查詢與資源相關的選項和需求
應用舉例：
GET方法：在瀏覽器的地址欄中輸入網址的方式訪問網頁時，瀏覽器採用GET方法向服務器獲取資源，
eg:GET /form.html HTTP/1.1 (CRLF)
POST方法要求被請求服務器接受附在請求後面的數據，常用於提交表單。
eg：POST /reg.jsp HTTP/ (CRLF)
響應的行稱爲狀態行,格式如下：HTTP-Version Status-Code Reason-Phrase CRLF
其中，HTTP-Version表示服務器HTTP協議的版本；
Status-Code表示服務器發回的響應狀態代碼；
Reason-Phrase表示狀態代碼的文本描述。
狀態代碼有三位數字組成，第一個數字定義了響應的類別，且有五種可能取值：
1xx：指示信息--表示請求已接收，繼續處理
2xx：成功--表示請求已被成功接收、理解、接受
3xx：重定向--要完成請求必須進行更進一步的操作
4xx：客戶端錯誤--請求有語法錯誤或請求無法實現
5xx：服務器端錯誤--服務器未能實現合法的請求
eg：HTTP/1.1 200 OK （CRLF）
HTTP頭字段包括4類： general-header ; request-header ; response-header ; entity-header .
general-header是request、response都可用的, 但是不能用於entity.
通用頭域包含請求和響應消息都支持的頭域，
包含Cache-Control、Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via。
Cache-Control
Cache -Control指定請求和響應遵循的緩存機制。
在請求消息或響應消息中設置 Cache-Control並不會修改另一個消息處理過程中的緩存處理過程。
請求時的緩存指令包括no-cache、no-store、max-age、 max-stale、min-fresh、only-if-cached，
響應消息中的指令包括public、private、no-cache、no- store、no-transform、must-revalidate、
proxy-revalidate、max-age。
經常使用的就是no-cache,表示不緩存。
Date
Date頭域表示消息發送的時間，時間的描述格式由rfc822定義。
例如，Date:Mon,31Dec200104:25:57GMT。
Date描述的時間表示世界標準時，換算成本地時間，需要知道用戶所在的時區。
Pragma
Pragma頭域用來包含實現特定的指令，最常用的是Pragma:no-cache。
在HTTP/1.1協議中，它的含義和Cache- Control:no-cache相同。
請求頭域可能包含下列字段Accept、Accept-Charset、Accept-Encoding、
Accept-Language、Authorization、From、Host、If-Modified-Since、
If- Match、If-None-Match、If-Range、If-Range、If-Unmodified-Since、
Max-Forwards、 Proxy-Authorization、Range、Referer、User-Agent。
| Header | 解釋 | 示例 |
|---|---|---|
| Accept | 指定客戶端能夠接收的內容類型 | Accept: text/plain, text/html |
| Accept-Charset | 瀏覽器可以接受的字符編碼集。 | Accept-Charset: iso-8859-5 |
| Accept-Encoding | 指定瀏覽器可以支持的web服務器返回內容壓縮編碼類型。 | Accept-Encoding: compress, gzip |
| Accept-Language | 瀏覽器可接受的語言 | Accept-Language: en,zh |
| Host | 指定請求的服務器的域名和端口號 | Host: www.zcmhi.com |
| From | 發出請求的用戶的Email | From: [email protected] |
| Referer | 先前網頁的地址，當前請求網頁緊隨其後,即來路 | Referer: http://www.zcmhi.com/archives/71.html |
| User-Agent | User-Agent的內容包含發出請求的用戶信息 | User-Agent: Mozilla/5.0 (Linux; X11) |
響應頭域允許服務器傳遞不能放在狀態行的附加信息，
這些域主要描述服務器的信息和 Request-URI進一步的信息。
響應頭域包含Age、Location、Proxy-Authenticate、Public、
Retry-After、Server、Vary、Warning、WWW-Authenticate。
| Header | 解釋 | 示例 |
|---|---|---|
| Age | 從原始服務器到代理緩存形成的估算時間（以秒計，非負） | Age: 12 |
| Location | 用來重定向接收方到非請求URL的位置來完成請求或標識新的資源 | Location: http://www.zcmhi.com/archives/94.html |
| Proxy-Authenticate | 它指出認證方案和可應用到代理的該URL上的參數 | Proxy-Authenticate: Basic |
| Server | web服務器軟件名稱 | Server: Apache/1.3.27 (Unix) (Red-Hat/Linux) |
| Retry-After | 如果實體暫時不可取，通知客戶端在指定時間之後再次嘗試 | Retry-After: 120 |
| Vary | 告訴下游代理是使用緩存響應還是從原始服務器請求 | Vary: * |
| Warning | 警告實體可能存在的問題 | Warning: 199 Miscellaneous warning |
| WWW-Authenticate | 表明客戶端請求實體應該使用的授權方案 | WWW-Authenticate: Basic |
實體頭域包含關於實體的原信息，實體頭包括Allow、Content- Base、Content-Encoding、
Content-Language、 Content-Length、Content-Location、Content-MD5、
Content-Range、Content-Type、 Etag、Expires、Last-Modified、extension-header。
| Header | 解釋 | 示例 |
|---|---|---|
| Allow | 對某網絡資源的有效的請求行爲，不允許則返回405 | Allow: GET, HEAD |
| Content-Encoding | web服務器支持的返回內容壓縮編碼類型。 | Content-Encoding: gzip |
| Content-Language | 響應體的語言 | Content-Language: en,zh |
| Content-Length | 響應體的長度 | Content-Length: 348 |
| Content-Location | 請求資源可替代的備用的另一地址 | Content-Location: /index.htm |
| Content-MD5 | 返回資源的MD5校驗值 | Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ== |
| Content-Range | 在整個返回體中本部分的字節位置 | Content-Range: bytes 21010-47021/47022 |
| Content-Type | 返回內容的MIME類型 | Content-Type: text/html; charset=utf-8 |
| ETag | 請求變量的實體標籤的當前值 | ETag: “737060cd8c284d8af7ad3082f209582d” |
| Expires | 響應過期的日期和時間 | Expires: Thu, 01 Dec 2010 16:00:00 GMT |
| Last-Modified | 請求資源的最後修改時間 | Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT |
看到這裏你可能會很奇怪，爲什麼會沒有Cookie，Content-Disposition這種常見的信息頭？！
這裏我說一下，Content-Disposition不是HTTP標準的一部分，但它在其他RFC文檔中定義了（RFC1806）。
而Cookie呢？首先看看Cookie是用來幹嘛的：Cookie和Session是爲了解決Http協議中無狀態的問題
，由於Http的設計者們時就沒打算讓Http有狀態這種特性，故Cookie這種東西是肯定不可能
是Http標準中的一部分。其實，它們都屬於上面所說的：extension-header。
The message-body (if any) of an HTTP message is used to carry the entity-body associated
with the request or response. The message-body differs from the entity-body only when a
transfer-coding has been applied, as indicated by the Transfer-Encoding header field.
(message-body = entity-body
| entity-body encoded as per Transfer-Encoding )
消息頭和消息體之間是一個空行，這個行非常重要，它表示消息頭已經結束，接下來的是消息體。
通常情況下Post方式請求的消息體,內容格式:param1=value1¶m2=value2
響應的消息體常見有html和json的消息體,
json格式:{"key1":"value1","key2":"value2"}
html格式:
<!DOCTYPE html>
<html lang="zh-cn">
...
...
</html>
三、 參考資料
(1)狀態碼詳細信息(2)更多消息頭的信息
(3)Http/1.1 Document
(4)RFC Archives