1. 程式人生 > >深入理解HTTP協議(二)——協議詳解篇

深入理解HTTP協議(二)——協議詳解篇

1.HTTP/1.0和HTTP/1.1的比較

RFC 1945定義了HTTP/1.0版本,RFC 2616定義了HTTP/1.1版本。

1.1建立連線方面

HTTP/1.0 每次請求都需要建立新的TCP連線,連線不能複用。HTTP/1.1 新的請求可以在上次請求建立的TCP連線之上傳送,連線可以複用。優點是減少重複進行TCP三次握手的開銷,提高效率。

注意:在同一個TCP連線中,新的請求需要等上次請求收到響應後,才能傳送。

1.2 Host

HTTP1.1在Request訊息頭裡頭多了一個Host域, HTTP1.0則沒有這個域。

Eg:

    GET /pub/WWW/TheProject.html HTTP/1.1
    Host: www.w3.org

可能HTTP1.0的時候認為,建立TCP連線的時候已經指定了IP地址,這個IP地址上只有一個host。

1.3日期時間戳

(接收方向)

無論是HTTP1.0還是HTTP1.1,都要能解析下面三種date/time stamp:

Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov 6 08:49:37 1994       ; ANSI C's asctime() format

(傳送方向)

HTTP1.0要求不能生成第三種asctime格式的date/time stamp;

HTTP1.1則要求只生成RFC 1123(第一種)格式的date/time stamp。

1.4狀態響應碼

狀態響應碼100 (Continue) 狀態程式碼的使用,允許客戶端在發request訊息body之前先用request header試探一下server,看server要不要接收request body,再決定要不要發request body。

客戶端在Request頭部中包含

Expect: 100-continue

Server看到之後呢如果回100 (Continue) 這個狀態程式碼,客戶端就繼續發request body。這個是HTTP1.1才有的。

另外在HTTP/1.1中還增加了101、203、205等等性狀態響應碼

1.5請求方式

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

2.HTTP請求訊息

2.1請求訊息格式

請求訊息格式如下所示:

請求行

通用資訊頭|請求頭|實體頭

CRLF(回車換行)

實體內容

其中“請求行”為:請求行 = 方法 [空格] 請求URI [空格] 版本號 [回車換行]

請求行例項:

Eg1:

GET /index.html HTTP/1.1

Eg2:

POST http://192.168.2.217:8080/index.jsp HTTP/1.1

HTTP請求訊息例項:

GET /hello.htm HTTP/1.1
Accept: */*
Accept-Language: zh-cn
Accept-Encoding: gzip, deflate
If-Modified-Since: Wed, 17 Oct 2007 02:15:55 GMT
If-None-Match: W/"158-1192587355000"
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Host: 192.168.2.162:8080
Connection: Keep-Alive

2.2請求方法

HTTP的請求方法包括如下幾種:

q      GET

q      POST

q      HEAD

q      PUT

q      DELETE

q      OPTIONS

q      TRACE

q      CONNECT

3.HTTP響應訊息

3.1響應訊息格式

HTTP響應訊息的格式如下所示:

狀態行

通用資訊頭|響應頭|實體頭

CRLF

實體內容

其中:狀態行 = 版本號 [空格] 狀態碼 [空格] 原因 [回車換行]

狀態行舉例:

Eg1:

HTTP/1.0 200 OK

Eg2:

HTTP/1.1 400 Bad Request

HTTP響應訊息例項如下所示:

HTTP/1.1 200 OK
ETag: W/"158-1192590101000"
Last-Modified: Wed, 17 Oct 2007 03:01:41 GMT
Content-Type: text/html
Content-Length: 158
Date: Wed, 17 Oct 2007 03:01:59 GMT
Server: Apache-Coyote/1.1

3.2 http的狀態響應碼

3.2.1  1**:請求收到,繼續處理

100——客戶必須繼續發出請求

101——客戶要求伺服器根據請求轉換HTTP協議版本

3.2.2  2**:操作成功收到,分析、接受

200——交易成功

201——提示知道新檔案的URL

202——接受和處理、但處理未完成

203——返回資訊不確定或不完整

204——請求收到,但返回資訊為空

205——伺服器完成了請求,使用者代理必須復位當前已經瀏覽過的檔案

206——伺服器已經完成了部分使用者的GET請求

3.2.3  3**:完成此請求必須進一步處理

300——請求的資源可在多處得到

301——刪除請求資料

302——在其他地址發現了請求資料

303——建議客戶訪問其他URL或訪問方式

304——客戶端已經執行了GET,但檔案未變化

305——請求的資源必須從伺服器指定的地址得到

306——前一版本HTTP中使用的程式碼,現行版本中不再使用

307——申明請求的資源臨時性刪除

3.2.4  4**:請求包含一個錯誤語法或不能完成

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頭欄位指定的期望值,如果是代理伺服器,可能是下一級伺服器不能滿足請求長。

3.2.5  5**:伺服器執行一個完全有效請求失敗

  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 - 閘道器錯誤

4.使用telnet進行http測試

在Windows下,可使用命令視窗進行http簡單測試。

輸入cmd進入命令視窗,在命令列鍵入如下命令後按回車:

telnet www.baidu.com 80

而後在視窗中按下“Ctrl+]”後按回車可讓返回結果回顯。

接著開始發請求訊息,例如傳送如下請求訊息請求baidu的首頁訊息,使用的HTTP協議為HTTP/1.1:

GET /index.html HTTP/1.1

注意:copy如上的訊息到命令視窗後需要按兩個回車換行才能得到響應的訊息,第一個回車換行是在命令後鍵入回車換行,是HTTP協議要求的。第二個是確認輸入,傳送請求。

可看到返回了200 OK的訊息,如下圖所示:

http協議學習和總結系列13

可看到,當採用HTTP/1.1時,連線不是在請求結束後就斷開的。若採用HTTP1.0,在命令視窗鍵入:

GET /index.html HTTP/1.0

此時可以看到請求結束之後馬上斷開。

讀者還可以嘗試在使用GET或POST等時,帶上頭域資訊,例如鍵入如下資訊:

GET /index.html HTTP/1.1
connection: close
Host: www.baidu.com

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 請求實現,因為在註解提交之後站點已經不同了(比方說文章下面出現一條註解)。

6.請求頭

HTTP最常見的請求頭如下:

l         Accept:瀏覽器可接受的MIME型別;

l         Accept-Charset:瀏覽器可接受的字符集;

l         Accept-Encoding:瀏覽器能夠進行解碼的資料編碼方式,比如gzip。Servlet能夠向支援gzip的瀏覽器返回經gzip編碼的HTML頁面。許多情形下這可以減少5到10倍的下載時間;

l         Accept-Language:瀏覽器所希望的語言種類,當伺服器能夠提供一種以上的語言版本時要用到;

l         Authorization:授權資訊,通常出現在對伺服器傳送的WWW-Authenticate頭的應答中;

l         Connection:表示是否需要持久連線。如果Servlet看到這裡的值為“Keep-Alive”,或者看到請求使用的是HTTP 1.1(HTTP 1.1預設進行持久連線),它就可以利用持久連線的優點,當頁面包含多個元素時(例如Applet,圖片),顯著地減少下載所需要的時間。要實現這一點,Servlet需要在應答中傳送一個Content-Length頭,最簡單的實現方法是:先把內容寫入ByteArrayOutputStream,然後在正式寫出內容之前計算它的大小;

l         Content-Length:表示請求訊息正文的長度;

l         Cookie:這是最重要的請求頭資訊之一;

l         From:請求傳送者的email地址,由一些特殊的Web客戶程式使用,瀏覽器不會用到它;

l         Host:初始URL中的主機和埠;

l         If-Modified-Since:只有當所請求的內容在指定的日期之後又經過修改才返回它,否則返回304“Not Modified”應答;

l         Pragma:指定“no-cache”值表示伺服器必須返回一個重新整理後的文件,即使它是代理伺服器而且已經有了頁面的本地拷貝;

l         Referer:包含一個URL,使用者從該URL代表的頁面出發訪問當前請求的頁面。

l         User-Agent:瀏覽器型別,如果Servlet返回的內容與瀏覽器型別有關則該值非常有用;

l         UA-Pixels,UA-Color,UA-OS,UA-CPU:由某些版本的IE瀏覽器所傳送的非標準的請求頭,表示螢幕大小、顏色深度、作業系統和CPU型別。

7.響應頭

HTTP最常見的響應頭如下所示:

l         Allow:伺服器支援哪些請求方法(如GET、POST等);

l         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頁面,為其他瀏覽器返回普通頁面;

l         Content-Length:表示內容長度。只有當瀏覽器使用持久HTTP連線時才需要這個資料。如果你想要利用持久連線的優勢,可以把輸出文件寫入ByteArrayOutputStram,完成後檢視其大小,然後把該值放入Content-Length頭,最後通過byteArrayStream.writeTo(response.getOutputStream()傳送內容;

l         Content-Type: 表示後面的文件屬於什麼MIME型別。Servlet預設為text/plain,但通常需要顯式地指定為text/html。由於經常要設定Content-Type,因此HttpServletResponse提供了一個專用的方法setContentTyep。 可在web.xml檔案中配置副檔名和MIME型別的對應關係;

l         Date:當前的GMT時間。你可以用setDateHeader來設定這個頭以避免轉換時間格式的麻煩;

l         Expires:指明應該在什麼時候認為文件已經過期,從而不再快取它。

l         Last-Modified:文件的最後改動時間。客戶可以通過If-Modified-Since請求頭提供一個日期,該請求將被視為一個條件GET,只有改動時間遲於指定時間的文件才會返回,否則返回一個304(Not Modified)狀態。Last-Modified也可用setDateHeader方法來設定;

l         Location:表示客戶應當到哪裡去提取文件。Location通常不是直接設定的,而是通過HttpServletResponse的sendRedirect方法,該方法同時設定狀態程式碼為302;

l         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都支援它。

8.實體頭