RFC 1945定義了HTTP/1.0版本,RFC 2616定義了HTTP/1.1版本。
筆者在blog上提供了這兩個RFC中文版的下載地址。
RFC1945下載地址:
http://www.blogjava.net/Files/amigoxie/RFC1945(HTTP)中文版.rar
RFC2616下載地址:
http://www.blogjava.net/Files/amigoxie/RFC2616(HTTP)中文版.rar
HTTP/1.0 每次請求都需要建立新的TCP連接,連接不能複用。HTTP/1.1 新的請求可以在上次請求建立的TCP連接之上發送,連接可以複用。優點是減少重複進行TCP三次握手的開銷,提高效率。
注意:在同一個TCP連接中,新的請求需要等上次請求收到響應後,才能發送。
HTTP1.1在Request消息頭裏頭多了一個Host域, HTTP1.0則沒有這個域。
Eg:
可能HTTP1.0的時候認爲,建立TCP連接的時候已經指定了IP地址,這個IP地址上只有一個host。
(接收方向)
無論是HTTP1.0還是HTTP1.1,都要能解析下面三種date/time stamp:
(發送方向)
HTTP1.0要求不能生成第三種asctime格式的date/time stamp;
HTTP1.1則要求只生成RFC 1123(第一種)格式的date/time stamp。
狀態響應碼100 (Continue) 狀態代碼的使用,允許客戶端在發request消息body之前先用request header試探一下server,看server要不要接收request body,再決定要不要發request body。
客戶端在Request頭部中包含
Server看到之後呢如果回100 (Continue) 這個狀態代碼,客戶端就繼續發request body。這個是HTTP1.1纔有的。
另外在HTTP/1.1中還增加了101、203、205等等性狀態響應碼
HTTP1.1增加了OPTIONS, PUT, DELETE, TRACE, CONNECT這些Request方法.
Method = "OPTIONS" ; Section 9.2
| "GET" ; Section 9.3
| "HEAD" ; Section 9.4
| "POST" ; Section 9.5
| "PUT" ; Section 9.6
| "DELETE" ; Section 9.7
| "TRACE" ; Section 9.8
| "CONNECT" ; Section 9.9
| extension-method
extension-method = token
請求消息格式如下所示:
請求行
通用信息頭|請求頭|實體頭
CRLF(回車換行)
實體內容
其中「請求行」爲:請求行 = 方法 [空格] 請求URI [空格] 版本號 [回車換行]
請求行實例:
Eg1:
Eg2:
POST http://192.168.2.217:8080/index.jsp HTTP/1.1
HTTP請求消息實例:
HTTP的請求方法包括如下幾種:
q GET
q POST
q HEAD
q PUT
q DELETE
q OPTIONS
q TRACE
q CONNECT
HTTP響應消息的格式如下所示:
狀態行
通用信息頭|響應頭|實體頭
CRLF
實體內容
其中:狀態行 = 版本號 [空格] 狀態碼 [空格] 原因 [回車換行]
狀態行舉例:
Eg1:
Eg2:
HTTP響應消息實例如下所示:
2.3.2 http的狀態響應碼
100——客戶必須繼續發出請求
101——客戶要求服務器根據請求轉換HTTP協議版本
200——交易成功
201——提示知道新文件的URL
202——接受和處理、但處理未完成
203——返回信息不確定或不完整
204——請求收到,但返回信息爲空
205——服務器完成了請求,用戶代理必須復位當前已經瀏覽過的文件
206——服務器已經完成了部分用戶的GET請求
300——請求的資源可在多處得到
301——刪除請求數據
302——在其他地址發現了請求數據
303——建議客戶訪問其他URL或訪問方式
304——客戶端已經執行了GET,但文件未變化
305——請求的資源必須從服務器指定的地址得到
306——前一版本HTTP中使用的代碼,現行版本中不再使用
307——申明請求的資源臨時性刪除
400——錯誤請求,如語法錯誤
401——未授權
HTTP 401.1 - 未授權:登錄失敗
HTTP 401.2 - 未授權:服務器配置問題導致登錄失敗
HTTP 401.3 - ACL 禁止訪問資源
HTTP 401.4 - 未授權:授權被篩選器拒絕
HTTP 401.5 - 未授權:ISAPI 或 CGI 授權失敗
402——保留有效ChargeTo頭響應
403——禁止訪問
HTTP 403.1 禁止訪問:禁止可執行訪問
HTTP 403.2 - 禁止訪問:禁止讀訪問
HTTP 403.3 - 禁止訪問:禁止寫訪問
HTTP 403.4 - 禁止訪問:要求 SSL
HTTP 403.5 - 禁止訪問:要求 SSL 128
HTTP 403.6 - 禁止訪問:IP 地址被拒絕
HTTP 403.7 - 禁止訪問:要求客戶證書
HTTP 403.8 - 禁止訪問:禁止站點訪問
HTTP 403.9 - 禁止訪問:連接的用戶過多
HTTP 403.10 - 禁止訪問:配置無效
HTTP 403.11 - 禁止訪問:密碼更改
HTTP 403.12 - 禁止訪問:映射器拒絕訪問
HTTP 403.13 - 禁止訪問:客戶證書已被吊銷
HTTP 403.15 - 禁止訪問:客戶訪問許可過多
HTTP 403.16 - 禁止訪問:客戶證書不可信或者無效
HTTP 403.17 - 禁止訪問:客戶證書已經到期或者尚未生效
404——沒有發現文件、查詢或URl
405——用戶在Request-Line字段定義的方法不允許
406——根據用戶發送的Accept拖,請求資源不可訪問
407——類似401,用戶必須首先在代理服務器上得到授權
408——客戶端沒有在用戶指定的餓時間內完成請求
409——對當前資源狀態,請求不能完成
410——服務器上不再有此資源且無進一步的參考地址
411——服務器拒絕用戶定義的Content-Length屬性請求
412——一個或多個請求頭字段在當前請求中錯誤
413——請求的資源大於服務器允許的大小
414——請求的資源URL長於服務器允許的長度
415——請求資源不支持請求項目格式
416——請求中包含Range請求頭字段,在當前請求資源範圍內沒有range指示值,請求也不包含If-Range請求頭字段
417——服務器不滿足請求Expect頭字段指定的期望值,如果是代理服務器,可能是下一級服務器不能滿足請求長。
HTTP 500 - 內部服務器錯誤
HTTP 500.100 - 內部服務器錯誤 - ASP 錯誤
HTTP 500-11 服務器關閉
HTTP 500-12 應用程序重新啓動
HTTP 500-13 - 服務器太忙
HTTP 500-14 - 應用程序無效
HTTP 500-15 - 不允許請求 global.asa
Error 501 - 未實現
HTTP 502 - 網關錯誤
在Windows下,可使用命令窗口進行http簡單測試。
輸入cmd進入命令窗口,在命令行鍵入如下命令後按回車:
而後在窗口中按下「Ctrl+]」後按回車可讓返回結果回顯。
接着開始發請求消息,例如發送如下請求消息請求baidu的首頁消息,使用的HTTP協議爲HTTP/1.1:
注意:copy如上的消息到命令窗口後需要按兩個回車換行才能得到響應的消息,第一個回車換行是在命令後鍵入回車換行,是HTTP協議要求的。第二個是確認輸入,發送請求。
可看到返回了200 OK的消息,如下圖所示:
可看到,當採用HTTP/1.1時,連接不是在請求結束後就斷開的。若採用HTTP1.0,在命令窗口鍵入:
此時可以看到請求結束之後馬上斷開。
讀者還可以嘗試在使用GET或POST等時,帶上頭域信息,例如鍵入如下信息:
我試了下,結果不盡人意:
打開這個telnet的開關 win7
然後就不知所措啦。好像地址變啦。首頁不是index.html了,我換了.php還是錯的信息。
2.5 常用的請求方式
常用的請求方式是GET和POST.
l GET方式:是以實體的方式得到由請求URI所指定資源的信息,如果請求URI只是一個數據產生過程,那麼最終要在響應實體中返回的是處理過程的結果所指向的資源,而不是處理過程的描述。
l POST方式:用來向目的服務器發出請求,要求它接受被附在請求後的實體,並把它當作請求隊列中請求URI所指定資源的附加新子項,Post被設計成用統一的方法實現下列功能:
1:對現有資源的解釋;
2:向電子公告欄、新聞組、郵件列表或類似討論組發信息;
3:提交數據塊;
4:通過附加操作來擴展數據庫 。
從上面描述可以看出,Get是向服務器發索取數據的一種請求;而Post是向服務器提交數據的一種請求,要提交的數據位於信息頭後面的實體中。
GET與POST方法有以下區別:
(1) 在客戶端,Get方式在通過URL提交數據,數據在URL中可以看到;POST方式,數據放置在HTML HEADER內提交。
(2) GET方式提交的數據最多隻能有1024字節,而POST則沒有此限制。
(3) 安全性問題。正如在(1)中提到,使用 Get 的時候,參數會顯示在地址欄上,而 Post 不會。所以,如果這些數據是中文數據而且是非敏感數據,那麼使用 get;如果用戶輸入的數據不是中文字符而且包含敏感數據,那麼還是使用 post爲好。
(4) 安全的和冪等的。所謂安全的意味着該操作用於獲取信息而非修改信息。冪等的意味着對同一 URL 的多個請求應該返回同樣的結果。完整的定義並不像看起來那樣嚴格。換句話說,GET 請求一般不應產生副作用。從根本上講,其目標是當用戶打開一個鏈接時,她可以確信從自身的角度來看沒有改變資源。比如,新聞站點的頭版不斷更新。雖然第二次請求會返回不同的一批新聞,該操作仍然被認爲是安全的和冪等的,因爲它總是返回當前的新聞。反之亦然。POST 請求就不那麼輕鬆了。POST 表示可能改變服務器上的資源的請求。仍然以新聞站點爲例,讀者對文章的註解應該通過 POST 請求實現,因爲在註解提交之後站點已經不同了(比方說文章下面出現一條註解)。