http請求和響應格式
當瀏覽器向Web伺服器發出請求時,它向伺服器傳遞了一個數據塊,也就是請求資訊,HTTP請求資訊由3部分組成:
l 請求方法URI協議/版本
l 請求頭(Request Header)
l 請求正文
下面是一個HTTP請求的例子:
GET/sample.jspHTTP/1.1
Accept:image/gif.image/jpeg,*/*
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)
Accept-Encoding:gzip,deflate
username=jinqiao&password=1234
(1)請求方法URI協議/版本
請求的第一行是“方法URL議/版本”:GET/sample.jsp HTTP/1.1
以上程式碼中“GET”代表請求方法,“/sample.jsp”表示URI,“HTTP/1.1代表協議和協議的版本。
根據HTTP標準,HTTP請求可以使用多種請求方法。例如:HTTP1.1目前支援7種請求方法:GET、POST、HEAD、OPTIONS、PUT、DELETE和TARCE。
但其實我們大部分情況下只用到了GET和POST。如果想設計一個符合RESTful規範的web應用程式,則這六種方法都會用到。不過即使暫時不想涉及REST,瞭解這六種方法的本質仍然是很有作用的。大家將會發現,原來web也是很簡潔明瞭的。下面依次說明這六種方法。
- GET:GET可以說是最常見的了,它本質就是傳送一個請求來取得伺服器上的某一資源。資源通過一組HTTP頭和呈現資料(如HTML文字,或者圖片或者視訊等)返回給客戶端。GET請求中,永遠不會包含呈現資料。
- HEAD:HEAD和GET本質是一樣的,區別在於HEAD不含有呈現資料,而僅僅是HTTP頭資訊。有的人可能覺得這個方法沒什麼用,其實不是這樣的。想象一個業務情景:欲判斷某個資源是否存在,我們通常使用GET,但這裡用HEAD則意義更加明確。
- PUT:這個方法比較少見。HTML表單也不支援這個。本質上來講, PUT和POST極為相似,都是向伺服器傳送資料,但它們之間有一個重要區別,PUT通常指定了資源的存放位置,而POST則沒有,POST的資料存放位置由伺服器自己決定。舉個例子:如一個用於提交博文的URL,/addBlog。如果用PUT,則提交的URL會是像這樣的”/addBlog/abc123”,其中abc123就是這個博文的地址。而如果用POST,則這個地址會在提交後由伺服器告知客戶端。目前大部分部落格都是這樣的。顯然,PUT和POST用途是不一樣的。具體用哪個還取決於當前的業務場景。
- DELETE:刪除某一個資源。基本上這個也很少見,不過還是有一些地方比如amazon的S3雲服務裡面就用的這個方法來刪除資源。
- POST:向伺服器提交資料。這個方法用途廣泛,幾乎目前所有的提交操作都是靠這個完成。
- OPTIONS:這個方法很有趣,但極少使用。它用於獲取當前URL所支援的方法。若請求成功,則它會在HTTP頭中包含一個名為“Allow”的頭,值是所支援的方法,如“GET, POST”。
- 其實還有一個TRACE方法,不過這個基本上不會用到,這裡就不介紹了。
URI完整地指定了要訪問的網路資源,通常只要給出相對於伺服器的根目錄的相對目錄即可,因此總是以“/”開頭,最後,協議版本聲明瞭通訊過程中使用HTTP的版本。
(2)請求頭(Request Header)
請求頭包含許多有關的客戶端環境和請求正文的有用資訊。例如,請求頭可以宣告瀏覽器所用的語言,請求正文的長度等。
Accept:image/gif.image/jpeg.*/*
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible:MSIE5.01:Windows NT5.0)
Accept-Encoding:gzip,deflate.
(3)請求正文
請求頭和請求正文之間是一個空行,這個行非常重要,它表示請求頭已經結束,接下來的是請求正文。請求正文中可以包含客戶提交的查詢字串資訊:
username=jinqiao&password=1234
在以上的例子的HTTP請求中,請求的正文只有一行內容。當然,在實際應用中,HTTP請求正文可以包含更多的內容。
HTTP請求方法我這裡只討論GET方法與POST方法
l GET方法
GET方法是預設的HTTP請求方法,我們日常用GET方法來提交表單資料,然而用GET方法提交的表單資料只經過了簡單的編碼,同時它將作為URL的一部分向Web伺服器傳送,因此,如果使用GET方法來提交表單資料就存在著安全隱患上。例如
Http://127.0.0.1/login.jsp?Name=zhangshi&Age=30&Submit=%cc%E+%BD%BB
從上面的URL請求中,很容易就可以辯認出表單提交的內容。(?之後的內容)另外由於GET方法提交的資料是作為URL請求的一部分所以提交的資料量不能太大
l POST方法
POST方法是GET方法的一個替代方法,它主要是向Web伺服器提交表單資料,尤其是大批量的資料。POST方法克服了GET方法的一些缺點。通過POST方法提交表單資料時,資料不是作為URL請求的一部分而是作為標準資料傳送給Web伺服器,這就克服了GET方法中的資訊無法保密和資料量太小的缺點。因此,出於安全的考慮以及對使用者隱私的尊重,通常表單提交時採用POST方法。
從程式設計的角度來講,如果使用者通過GET方法提交資料,則資料存放在QUERY_STRING環境變數中,而POST方法提交的資料則可以從標準輸入流中獲取。
http響應格式
HTTP應答與HTTP請求相似,HTTP響應也由3個部分構成,分別是:
l 狀態行
l 響應頭(Response Header)
l 響應正文
在接收和解釋請求訊息後,伺服器會返回一個HTTP響應訊息。
狀態行由協議版本、數字形式的狀態程式碼、及相應的狀態描述,各元素之間以空格分隔。
格式: HTTP-Version Status-Code Reason-Phrase CRLF
例如: HTTP/1.1 200 OK \r\n
狀態程式碼:
狀態程式碼由3位數字組成,表示請求是否被理解或被滿足。
狀態描述:
狀態描述給出了關於狀態程式碼的簡短的文字描述。
狀態程式碼的第一個數字定義了響應的類別,後面兩位沒有具體的分類。
第一個數字有五種可能的取值:
- 1xx: 指示資訊—表示請求已接收,繼續處理。
- 2xx: 成功—表示請求已經被成功接收、理解、接受。
- 3xx: 重定向—要完成請求必須進行更進一步的操作。
- 4xx: 客戶端錯誤—請求有語法錯誤或請求無法實現。
- 5xx: 伺服器端錯誤—伺服器未能實現合法的請求。
狀態程式碼狀態描述 說明
200 OK 客戶端請求成功
400 Bad Request 由於客戶端請求有語法錯誤,不能被伺服器所理解。
401 Unauthonzed 請求未經授權。這個狀態程式碼必須和WWW-Authenticate報頭域一起使用
403 Forbidden 伺服器收到請求,但是拒絕提供服務。伺服器通常會在響應正文中給出不提供服務的原因
404 Not Found 請求的資源不存在,例如,輸入了錯誤的URL。
500 Internal Server Error 伺服器發生不可預期的錯誤,導致無法完成客戶端的請求。
503 Service Unavailable 伺服器當前不能夠處理客戶端的請求,在一段時間之後,伺服器可能會恢復正常。
響應頭
響應頭可能包括:
Location:
Location響應報頭域用於重定向接受者到一個新的位置。例如:客戶端所請求的頁面已不存在原先的位置,為了讓客戶端重定向到這個頁面新的位置,伺服器端可以發回Location響應報頭後使用重定向語句,讓客戶端去訪問新的域名所對應的伺服器上的資源。當我們在JSP中使用重定向語句的時候,伺服器端向客戶端發回的響應報頭中,就會有Location響應報頭域。
Server:
Server響應報頭域包含了伺服器用來處理請求的軟體資訊。它和User-Agent請求報頭域是相對應的,前者傳送伺服器端軟體的資訊,後者傳送客戶端軟體(瀏覽器)和作業系統的資訊。下面是Server響應報頭域的一個例子:Server: Apache-Coyote/1.1
WWW-Authenticate:
WWW-Authenticate響應報頭域必須被包含在401(未授權的)響應訊息中,這個報頭域和前面講到的Authorization請求報頭域是相關的,當客戶端收到401響應訊息,就要決定是否請求伺服器對其進行驗證。如果要求伺服器對其進行驗證,就可以傳送一個包含了 Authorization報頭域的請求,下面是WWW-Authenticate響應報頭域的一個例子:WWW-Authenticate: Basic realm="Basic Auth Test!"
從這個響應報頭域,可以知道伺服器端對我們所請求的資源採用的是基本驗證機制。
Content-Encoding:
Content-Encoding實體報頭域被使用作媒體型別的修飾符,它的值指示了已經被應用到實體正文的附加內容編碼,因而要獲得Content- Type報頭域中所引用的媒體型別,必須採用相應的解碼機制。Content-Encoding主要用語記錄文件的壓縮方法,下面是它的一個例子: Content-Encoding: gzip。如果一個實體正文采用了編碼方式儲存,在使用之前就必須進行解碼。
Content-Language:
Content-Language實體報頭域描述了資源所用的自然語言。Content-Language允許使用者遵照自身的首選語言來識別和區分實體。如果這個實體內容僅僅打算提供給丹麥的閱讀者,那麼可以按照如下的方式設定這個實體報頭域:Content-Language: da。
如果沒有指定Content-Language報頭域,那麼實體內容將提供給所以語言的閱讀者。
Content-Length:
Content-Length實體報頭域用於指明正文的長度,以位元組方式儲存的十進位制數字來表示,也就是一個數字字元佔一個位元組,用其對應的ASCII碼儲存傳輸。
要注意的是:這個長度僅僅是表示實體正文的長度,沒有包括實體報頭的長度。
Content-Type
Content-Type實體報頭域用語指明發送給接收者的實體正文的媒體型別。例如:
Content-Type: text/html;charset=ISO-8859-1
Content-Type: text/html;charset=GB2312
Last-Modified
Last-Modified實體報頭域用於指示資源最後的修改日期及時間。
Expires
Expires實體報頭域給出響應過期的日期和時間。通常,代理伺服器或瀏覽器會快取一些頁面。當用戶再次訪問這些頁面時,直接從快取中載入並顯示給使用者,這樣縮短了響應的時間,減少伺服器的負載。為了讓代理伺服器或瀏覽器在一段時間後更新頁面,我們可以使用Expires實體報頭域指定頁面過期的時間。當用戶又一次訪問頁面時,如果Expires報頭域給出的日期和時間比Date普通報頭域給出的日期和時間要早(或相同),那麼代理伺服器或瀏覽器就不會再使用快取的頁面而是從伺服器上請求更新的頁面。不過要注意,即使頁面過期了,也並不意味著伺服器上的原始資源在此時間之前或之後發生了改變。
Expires實體報頭域使用的日期和時間必須是RFC 1123中的日期格式,例如:
Expires: Thu, 15 Sep 2005 16:00:00 GMT
HTTP1.1的客戶端和快取必須將其他非法的日期格式(也包括0)看作已過期。例如,為了讓瀏覽器不要快取頁面,我們也可以利用Expires實體報頭域,設定它的值為0,如下(JSP):response.setDateHeader("Expires",0);
下面是一個HTTP響應的例子:
HTTP/1.1 200 OK
Server:Apache Tomcat/5.0.12
Date:Mon,6Oct2003 13:23:42 GMT
Content-Length:112