HTTP协议的头信息详解
?HTTP協議的頭信息詳解?
http://blog.csdn.net/guoguo1980/archive/2008/07/14/2649658.aspx
?
HTTP協議的頭信息詳解
HTTP（HyperTextTransferProtocol）是超文本傳輸協議的縮寫，它用于傳送WWW方式的數據，關于HTTP 協議的詳細內容請參 考RFC2616。HTTP協議采用了請求/響應模型。客戶端向服務器發送一個請求，請求頭包含請求的方法、URI、協議版本、以及包含請求修飾符、客戶 信息和內容的類似于MIME的消息結構。服務器以一個狀態行作為響應，相應的內容包括消息協議的版本，成功或者錯誤編碼加上包含服務器信息、實體元信息以 及可能的實體內容。?
通常HTTP消息包括客戶機向服務器的請求消息和服務器向客戶機的響應消息。這兩種類型的消息由一個起始行，一個或者多個頭域，一個只是頭域結束的空行和可 選的消息體組成。HTTP的頭域包括通用頭，請求頭，響應頭和實體頭四個部分。每個頭域由一個域名，冒號（:）和域值三部分組成。域名是大小寫無關的，域 值前可以添加任何數量的空格符，頭域可以被擴展為多行，在每行開始處，使用至少一個空格或制表符。?
通用頭域?
通用頭 域包含請求和響應消息都支持的頭域，通用頭域包含Cache-Control、 Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via。對通用頭域的擴展要求通訊雙方都支持此擴 展，如果存在不支持的通用頭域，一般將會作為實體頭域處理。下面簡單介紹幾個在UPnP消息中使用的通用頭域。?
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。各個消息中的指令含義如 下：?
Public指示響應可被任何緩存區緩存。?
Private指示對于單個用戶的整個或部分響應消息，不能被共享緩存處理。這允許服務器僅僅描述當用戶的部分響應消息，此響應消息對于其他用戶的請求無效。?
no-cache指示請求或響應消息不能緩存?
no-store用于防止重要的信息被無意的發布。在請求消息中發送將使得請求和響應消息都不使用緩存。?
max-age指示客戶機可以接收生存期不大于指定時間（以秒為單位）的響應。?
min-fresh指示客戶機可以接收響應時間小于當前時間加上指定時間的響應。?
max-stale指示客戶機可以接收超出超時期間的響應消息。如果指定max-stale消息的值，那么客戶機可以接收超出超時期指定值之內的響應消息。?
Date頭域?
Date頭域表示消息發送的時間，時間的描述格式由rfc822定義。例如，Date:Mon,31Dec200104:25:57GMT。Date描述的時間表示世界標準時，換算成本地時間，需要知道用戶所在的時區。?
Pragma頭域?
Pragma頭域用來包含實現特定的指令，最常用的是Pragma:no-cache。在HTTP/1.1協議中，它的含義和Cache- Control:no-cache相同。?
請求消息?
請求消息的第一行為下面的格式：?
MethodSPRequest-URISPHTTP-VersionCRLFMethod 表示對于Request-URI完成的方法，這個字段是大小寫敏感的，包括OPTIONS、GET、HEAD、POST、PUT、DELETE、 TRACE。方法GET和HEAD應該被所有的通用WEB服務器支持，其他所有方法的實現是可選的。GET方法取回由Request-URI標識的信息。 HEAD方法也是取回由Request-URI標識的信息，只是可以在響應時，不返回消息體。POST方法可以請求服務器接收包含在請求中的實體信息，可 以用于提交表單，向新聞組、BBS、郵件群組和數據庫發送消息。?
SP表示空格。Request-URI遵循URI格式，在此字段為星 號（*）時，說明請求并不用于某個特定的資源地址，而是用于服務器本身。HTTP- Version表示支持的HTTP版本，例如為HTTP/1.1。CRLF表示換行回車符。請求頭域允許客戶端向服務器傳遞關于請求或者關于客戶機的附加 信息。請求頭域可能包含下列字段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。對請求頭域的擴展要求通訊雙方都支持，如果存在不支持的請 求頭域，一般將會作為實體頭域處理。?
典型的請求消息：?
GET http://download.microtool.de:80/somedata.exe?
Host: download.microtool.de?
Accept:*/*?
Pragma: no-cache?
Cache-Control: no-cache?
Referer: http://download.microtool.de/?
User-Agent:Mozilla/4.04[en](Win95;I;Nav)?
Range:bytes=554554-?
上例第一行表示HTTP客戶端（可能是瀏覽器、下載程序）通過GET方法獲得指定URL下的文件。棕色的部分表示請求頭域的信息，綠色的部分表示通用頭部分。?
Host頭域?
Host頭域指定請求資源的Intenet主機和端口號，必須表示請求url的原始服務器或網關的位置。HTTP/1.1請求必須包含主機頭域，否則系統會以400狀態碼返回。?
Referer頭域?
Referer 頭域允許客戶端指定請求uri的源資源地址，這可以允許服務器生成回退鏈表，可用來登陸、優化cache等。他也允許廢除的或錯誤的連接由于維護的目的被 追蹤。如果請求的uri沒有自己的uri地址，Referer不能被發送。如果指定的是部分uri地址，則此地址應該是一個相對地址。?
Range頭域?
Range頭域可以請求實體的一個或者多個子范圍。例如，?
表示頭500個字節：bytes=0-499?
表示第二個500字節：bytes=500-999?
表示最后500個字節：bytes=-500?
表示500字節以后的范圍：bytes=500-?
第一個和最后一個字節：bytes=0-0,-1?
同時指定幾個范圍：bytes=500-600,601-999?
但是服務器可以忽略此請求頭，如果無條件GET包含Range請求頭，響應會以狀態碼206（PartialContent）返回而不是以200 （OK）。?
User-Agent頭域?
User-Agent頭域的內容包含發出請求的用戶信息。?
響應消息?
響應消息的第一行為下面的格式：?
HTTP-VersionSPStatus-CodeSPReason-PhraseCRLF?
HTTP -Version表示支持的HTTP版本，例如為HTTP/1.1。Status- Code是一個三個數字的結果代碼。Reason-Phrase給Status-Code提供一個簡單的文本描述。Status-Code主要用于機器自 動識別，Reason-Phrase主要用于幫助用戶理解。Status-Code的第一個數字定義響應的類別，后兩個數字沒有分類的作用。第一個數字可 能取5個不同的值：?
1xx:信息響應類，表示接收到請求并且繼續處理?
2xx:處理成功響應類，表示動作被成功接收、理解和接受?
3xx:重定向響應類，為了完成指定的動作，必須接受進一步處理?
4xx:客戶端錯誤，客戶請求包含語法錯誤或者是不能正確執行?
5xx:服務端錯誤，服務器不能正確執行一個正確的請求?
響應頭域允許服務器傳遞不能放在狀態行的附加信息，這些域主要描述服務器的信息和 Request-URI進一步的信息。響應頭域包含Age、Location、Proxy-Authenticate、Public、Retry- After、Server、Vary、Warning、WWW-Authenticate。對響應頭域的擴展要求通訊雙方都支持，如果存在不支持的響應頭 域，一般將會作為實體頭域處理。?
典型的響應消息：?
HTTP/1.0200OK?
Date:Mon,31Dec200104:25:57GMT?
Server:Apache/1.3.14(Unix)?
Content-type:text/html?
Last-modified:Tue,17Apr200106:46:28GMT?
Etag:"a030f020ac7c01:1e9f"?
Content-length:39725426?
Content-range:bytes554554-40279979/40279980?
上例第一行表示HTTP服務端響應一個GET方法。棕色的部分表示響應頭域的信息，綠色的部分表示通用頭部分，紅色的部分表示實體頭域的信息。?
Location響應頭?
Location響應頭用于重定向接收者到一個新URI地址。?
Server響應頭?
Server響應頭包含處理請求的原始服務器的軟件信息。此域能包含多個產品標識和注釋，產品標識一般按照重要性排序。?
實體?
請求消息和響應消息都可以包含實體信息，實體信息一般由實體頭域和實體組成。實體頭域包含關于實體的原信息，實體頭包括Allow、Content- Base、Content-Encoding、Content-Language、 Content-Length、Content-Location、Content-MD5、Content-Range、Content-Type、 Etag、Expires、Last-Modified、extension-header。extension-header允許客戶端定義新的實體 頭，但是這些域可能無法未接受方識別。實體可以是一個經過編碼的字節流，它的編碼方式由Content-Encoding或Content-Type定 義，它的長度由Content-Length或Content-Range定義。?
Content-Type實體頭?
Content-Type實體頭用于向接收方指示實體的介質類型，指定HEAD方法送到接收方的實體介質類型，或GET方法發送的請求介質類型 Content-Range實體頭?
Content-Range實體頭用于指定整個實體中的一部分的插入位置，他也指示了整個實體的長度。在服務器向客戶返回一個部分響應，它必須描述響應覆蓋的范圍和整個實體長度。一般格式：?
Content-Range:bytes-unitSPfirst-byte-pos-last-byte-pos/entity-legth?
例如，傳送頭500個字節次字段的形式：Content-Range:bytes0- 499/1234如果一個http消息包含此節（例如，對范圍請求的響應或對一系列范圍的重疊請求），Content-Range表示傳送的范圍， Content-Length表示實際傳送的字節數。?
Last-modified實體頭?
| 應答頭 | 說明 |
| Allow | 服務器支持哪些請求方法（如GET、POST等）。 |
| 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頁面，為其他瀏覽器返回普通頁面。 |
| Content-Length | 表 示內容長度。只有當瀏覽器使用持久HTTP連接時才需要這個數據。如果你想要利用持久連接的優勢，可以把輸出文檔寫入 ByteArrayOutputStram，完成后查看其大小，然后把該值放入Content-Length頭，最后通過 byteArrayStream.writeTo(response.getOutputStream()發送內容。 |
| Content-Type | 表示后面的文檔屬于什么MIME類型。Servlet默認為text/plain，但通常需要顯式地指定為text/html。由于經常要設置Content-Type，因此HttpServletResponse提供了一個專用的方法setContentTyep。? |
| Date | 當前的GMT時間。你可以用setDateHeader來設置這個頭以避免轉換時間格式的麻煩。 |
| Expires | 應該在什么時候認為文檔已經過期，從而不再緩存它？ |
| Last-Modified | 文 檔的最后改動時間。客戶可以通過If-Modified-Since請求頭提供一個日期，該請求將被視為一個條件GET，只有改動時間遲于指定時間的文檔 才會返回，否則返回一個304（Not Modified）狀態。Last-Modified也可用setDateHeader方法來設置。 |
| Location | 表示客戶應當到哪里去提取文檔。Location通常不是直接設置的，而是通過HttpServletResponse的sendRedirect方法，該方法同時設置狀態代碼為302。 |
| 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都支持它。 |
| Server | 服務器名字。Servlet一般不設置這個值，而是由Web服務器自己設置。 |
| Set-Cookie | 設置和頁面關聯的Cookie。Servlet不應使用response.setHeader("Set-Cookie", ...)，而是應使用HttpServletResponse提供的專用方法addCookie。參見下文有關Cookie設置的討論。 |
| WWW-Authenticate | 客 戶應該在Authorization頭中提供什么類型的授權信息？在包含401（Unauthorized）狀態行的應答中這個頭是必需的。例如， response.setHeader("WWW-Authenticate", "BASIC realm=＼"executives＼"")。? 注意Servlet一般不進行這方面的處理，而是讓Web服務器的專門機制來控制受密碼保護頁面的訪問（例如.htaccess）。 |
（一）初識HTTP消息頭
但凡搞WEB開發的人都離不開HTTP（超文本傳輸協議），而要了解HTTP，除了HTML本身以外，還有一部分不可忽視的就是HTTP消息頭。做過Socket編程的人都知道，當我們設計一個通信協議時，“消息頭/消息體”的分割方式是很常用的，消息頭告訴對方這個消息是干什么的，消息體告訴對方怎么干。HTTP傳輸的消息也是這樣規定的，每一個HTTP包都分為HTTP頭和HTTP體兩部分，后者是可選的，而前者是必須的。每當我們打開一個網頁，在上面點擊右鍵，選擇“查看源文件”，這時看到的HTML代碼就是HTTP的消息體，那么消息頭又在哪呢？IE瀏覽器不讓我們看到這部分，但我們可以通過截取數據包等方法看到它。
下面就來看一個簡單的例子：
首先制作一個非常簡單的網頁，它的內容只有一行：
<html><body>hello world</body></html>
把它放到WEB服務器上，比如IIS，然后用IE瀏覽器請求這個頁面（http://localhost:8080/simple.htm），當我們請求這個頁面時，瀏覽器實際做了以下四項工作：
1 解析我們輸入的地址，從中分解出協議名、主機名、端口、對象路徑等部分，對于我們的這個地址，解析得到的結果如下：
協議名：http
主機名：localhost
端口：8080
對象路徑：/simple.htm
2 把以上部分結合本機自己的信息，封裝成一個HTTP請求數據包
3 使用TCP協議連接到主機的指定端口（localhost, 8080），并發送已封裝好的數據包
4 等待服務器返回數據，并解析返回數據，最后顯示出來
由截取到的數據包我們不難發現瀏覽器生成的HTTP數據包的內容如下：
GET /simple.htm HTTP/1.1<CR>
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*<CR>
Accept-Language: zh-cn<CR>
Accept-Encoding: gzip, deflate<CR>
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)<CR>
Host: localhost:8080<CR>
Connection:?Keep-Alive<CR>
<CR>
為了顯示清楚我把所有的回車的地方都加上了“<CR>”，注意最后還有一個空行加一個回車，這個空行正是HTTP規定的消息頭和消息體的分界線，第一個空行以下的內容就是消息體，這個請求數據包是沒有消息體的。
消息的第一行“GET”表示我們所使用的HTTP動作，其他可能的還有“POST”等，GET的消息沒有消息體，而POST消息是有消息體的，消息體的內容就是要POST的數據。后面/simple.htm就是我們要請求的對象，之后HTTP1.1表示使用的是HTTP1.1協議。
第二行表示我們所用的瀏覽器能接受的Content-type，三四兩行則是語言和編碼信息，第五行顯示出本機的相關系信息，包括瀏覽器類型、操作系統信息等，很多網站可以顯示出你所使用的瀏覽器和操作系統版本，就是因為可以從這里獲取到這些信息。
第六行表示我們所請求的主機和端口，第七行表示使用Keep-Alive方式，即數據傳遞完并不立即關閉連接。
服務器接收到這樣的數據包以后會根據其內容做相應的處理，例如查找有沒有“/simple.htm”這個對象，如果有，根據服務器的設置來決定如何處理，如果是HTM，則不需要什么復雜的處理，直接返回其內容即可。但在直接返回之前，還需要加上HTTP消息頭。
服務器發回的完整HTTP消息如下：
HTTP/1.1 200 OK<CR>
Server: Microsoft-IIS/5.1<CR>
X-Powered-By: ASP.NET<CR>
Date: Fri, 03 Mar 2006 06:34:03 GMT<CR>
Content-Type: text/html<CR>
Accept-Ranges: bytes<CR>
Last-Modified: Fri, 03 Mar 2006 06:33:18 GMT<CR>
ETag: "5ca4f75b8c3ec61:9ee"<CR>
Content-Length: 37<CR>
<CR>
<html><body>hello world</body></html>
同樣，我用“<CR>”來表示回車。可以看到，這個消息也是用空行切分成消息頭和消息體兩部分，消息體的部分正是我們前面寫好的HTML代碼。
消息頭第一行“HTTP/1.1”也是表示所使用的協議，后面的“200 OK”是HTTP返回代碼，200就表示操作成功，還有其他常見的如404表示對象未找到，500表示服務器錯誤，403表示不能瀏覽目錄等等。
第二行表示這個服務器使用的WEB服務器軟件，這里是IIS 5.1。第三行是ASP.Net的一個附加提示，沒什么實際用處。第四行是處理此請求的時間。第五行就是所返回的消息的content-type，瀏覽器會根據它來決定如何處理消息體里面的內容，例如這里是text/html，那么瀏覽器就會啟用HTML解析器來處理它，如果是image/jpeg，那么就會使用JPEG的解碼器來處理。
消息頭最后一行“Content-Length”表示消息體的長度，從空行以后的內容算起，以字節為單位，瀏覽器接收到它所指定的字節數的內容以后就會認為這個消息已經被完整接收了。
理解HTTP消息頭 （二）
常見的HTTP返回碼
上一篇文章里我簡要的說了說HTTP消息頭的格式，注意到在服務器返回的HTTP消息頭里有一個“HTTP/1.1 200 OK”，這里的200是HTTP規定的返回代碼，表示請求已經被正常處理完成。瀏覽器通過這個返回代碼就可以知道服務器對所發請求的處理情況是什么，每一種返回代碼都有自己的含義。這里列舉幾種常見的返回碼。1 403 Access Forbidden
如果我們試圖請求服務器上一個文件夾，而在WEB服務器上這個文件夾并沒有允許對這個文件夾列目錄的話，就會返回這個代碼。一個完整的403回復可能是這樣的：（IIS5.1）HTTP/1.1 403 Access Forbidden
Server: Microsoft-IIS/5.1
Date: Mon, 06 Mar 2006 08:57:39 GMT
Connection: close
Content-Type: text/html
Content-Length: 172 <html><head><title>Directory Listing Denied</title></head>
<body><h1>Directory Listing Denied</h1>This Virtual Directory does not allow contents to be listed.</body></html>
2 404 Object not found
當我們請求的對象在服務器上并不存在時，就會給出這個返回代碼，這可能也是最常見的錯誤代碼了。IIS給出的404消息內容很長，除了消息頭以外還有一個完整的說明“為什么會這樣”的網頁。APACHE服務器的404消息比較簡短，如下：HTTP/1.1 404 Not Found
Date: Mon, 06 Mar 2006 09:03:14 GMT
Server: Apache/2.0.55 (Unix) PHP/5.0.5
Content-Length: 291
Keep-Alive: timeout=15, max=100
Connection:?Keep-Alive
Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /notexist was not found on this server.</p>
<hr>
<address>Apache/2.0.55 (Unix) PHP/5.0.5 Server at localhost Port 8080</address>
</body></html> 也許你會問，無論是404還是200，都會在消息體內給出一個說明網頁，那么對于客戶端來說二者有什么區別呢？一個比較明顯的區別在于200是成功請求，瀏覽器會記錄下這個地址，以便下次再訪問時可以自動提示該地址，而404是失敗請求，瀏覽器只會顯示出返回的頁面內容，并不會記錄此地址，要再次訪問時還需要輸入完整的地址。
3 401 Access Denied
當WEB服務器不允許匿名訪問，而我們又沒有提供正確的用戶名/密碼時，服務器就會給出這個返回代碼。在IIS中，設置IIS的安全屬性為不允許匿名訪問（如下圖），此時直接訪問的話就會得到以下返回結果：HTTP/1.1 401 Access Denied
Server: Microsoft-IIS/5.1
Date: Mon, 06 Mar 2006 09:15:55 GMT
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
Connection: close
Content-Length: 3964
Content-Type: text/html <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html dir=ltr>
……
此時瀏覽器上給出的提示如下圖，讓我們輸入用戶名和密碼： 因返回信息中消息體較長，只取前面兩行內容。注意，如果是用localhost來訪問本機的IIS，因IE可以直接取得當前用戶的身份，它會和服務器間直接進行協商，所以不會看到401提示。
當我們在輸入了用戶名和密碼以后，服務器與客戶端會再進行兩次對話。首先客戶端向服務器索取一個公鑰，服務器端會返回一個公鑰，二者都用BASE64編碼，相應的消息如下（編碼部分已經做了處理）： GET / HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Accept-Language: zh-cn
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Host: 192.168.0.55:8080
Connection:?Keep-Alive
Authorization: Negotiate ABCDEFG…… HTTP/1.1 401 Access Denied
Server: Microsoft-IIS/5.1
Date: Mon, 06 Mar 2006 09:20:53 GMT
WWW-Authenticate: Negotiate HIJKLMN……
Content-Length: 3715
Content-Type: text/html <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html dir=ltr>
……
客戶端拿到公鑰之后使用公鑰對用戶名和密碼進行加密碼，然后把加密以后的結果重新發給服務器：
GET / HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Accept-Language: zh-cn
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Host: 192.168.0.55:8080
Connection:?Keep-Alive
Authorization: Negotiate OPQRST…… 這樣，如果驗證通過，服務器端就會把請求的內容發送過來了，也就是說禁止匿名訪問的網站會經過三次請求才可以看到頁面。但因為客戶端瀏覽器已經緩存了公鑰，用同一個瀏覽器窗口再次請求這個網站上的其它頁面時就可以直接發送驗證信息，從而一次交互就可以完成了。
4 302 Object Moved
用過ASP的人都知道ASP中頁面重定向至少有Redirect和Transfer兩種方法。二的區別在于Redirect是客戶端重定向，而Transfer是服務器端重定向，那么它們具體是如何通過HTTP消息頭實現的呢？先來看一下Transfer的例子：
例如ASP文件1.asp只有一行
<% Server.Transfer "1.htm" %>
HTML文件1.htm也只有一行：
<p>this is 1.htm</p>
如果我們從瀏覽器里請求1.asp，發送的請求是：
GET /1.asp HTTP/1.1
Accept: */*
Accept-Language: zh-cn
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Host: localhost:8080
Connection:?Keep-Alive
Cookie: ASPSESSIONIDACCTRTTT=PKKDJOPBAKMAMBNANIPIFDAP 注意請求的文件確實是1.asp，而得到的回應則是：
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.1
Date: Mon, 06 Mar 2006 12:52:44 GMT
X-Powered-By: ASP.NET
Content-Length: 20
Content-Type: text/html
Cache-control: private <p>this is 1.htm</p>
不難看出，通過Server.Transfer語句服務器端已經做了頁面重定向，而客戶端對此一無所知，表面上看上去得到的就是1.asp的結果。
如果把1.asp的內容改為：
<% Response.Redirect "1.htm" %>
再次請求1.asp，發送的請求沒有變化，得到的回應卻變成了：
HTTP/1.1 302 Object moved
Server: Microsoft-IIS/5.1
Date: Mon, 06 Mar 2006 12:55:57 GMT
X-Powered-By: ASP.NET
Location: 1.htm
Content-Length: 121
Content-Type: text/html
Cache-control: private <head><title>Object moved</title></head>
<body><h1>Object Moved</h1>This object may be found <a HREF="">here</a>.</body> 注意HTTP的返回代碼由200變成了302，表示這是一個重定向消息，客戶端需要根據消息頭中Location字段的值重新發送請求，于是就有了下面一組對話：
GET /1.htm HTTP/1.1
Accept: */*
Accept-Language: zh-cn
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Host: localhost:8080
Connection:?Keep-Alive
If-Modified-Since: Thu, 02 Mar 2006 06:50:13 GMT
If-None-Match: "b224758ec53dc61:9f0"
Cookie: ASPSESSIONIDACCTRTTT=PKKDJOPBAKMAMBNANIPIFDAP
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.1
X-Powered-By: ASP.NET
Date: Mon, 06 Mar 2006 12:55:57 GMT
Content-Type: text/html
Accept-Ranges: bytes
Last-Modified: Mon, 06 Mar 2006 12:52:32 GMT
ETag: "76d85bd51c41c61:9f0"
Content-Length: 20 <p>this is 1.htm</p>
很明顯，兩種重定向方式雖然看上去結果很像，但在實現原理上有很大的不同。
5 500 Internal Server Error
500號錯誤發生在服務器程序有錯誤的時候，例如，ASP程序為<% if %>
顯然這個程序并不完整，于是得到的結果為：
HTTP/1.1 500 Internal Server Error
Server: Microsoft-IIS/5.1
Date: Mon, 06 Mar 2006 12:58:55 GMT
X-Powered-By: ASP.NET
Content-Length: 4301
Content-Type: text/html
Expires: Mon, 06 Mar 2006 12:58:55 GMT
Set-Cookie: ASPSESSIONIDACCTRTTT=ALKDJOPBPPKNPCNOEPCNOOPD; path=/
Cache-control: private
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <html dir=ltr>
…… 服務器發送了500號錯誤，并且后面通過HTML的方式說明了錯誤的原因。
理解HTTP消息頭 （三）
（三） 客戶端發送的內容
這一次主要來觀察HTTP消息頭中客戶端的請求，從中找到一些有意思的內容。 1 HTTP_REFERER
寫兩個簡單的網頁：
a.htm：
<a href=b.htm>to page b</a>
b.htm：
haha
內容很簡單，就是網頁A中有一個到B的鏈接。把它們放到IIS上，并訪問網頁A，從中再點擊到B的鏈接，于是看到了B頁的“haha”。那么這兩次請求有什么不同嗎？觀察它們所發送的HTTP消息頭，最明顯的區別就是訪問B頁時比訪問A頁時多了一行：
Referer:?http://localhost/a.htm
這一行就表示，用戶要訪問的B頁是從A頁鏈接過來的。
服務器端要想取得這個值也是很容易的，以ASP為例，只需要寫一句
<% =Request.ServerVariables("HTTP_REFERER") %>
就可以了。
一些網站通過HTTP_REFERER來做安全驗證，判斷用戶是不是從允許的頁面鏈接來的，而不是直接從瀏覽器上打URL或從其他頁面鏈接過來，這樣可以從一定程度上防止網頁被做非法使用。但從上述原理來看，想要騙過服務器也并不困難，只要手工構造輸入的HTTP消息頭就可以了，其他常用的手段還有通過HOSTS文件偽造域名等。
除了超鏈接以外，還有其他幾種方式會導致HTTP_REFERER信息被發送，如：
內聯框架：<iframe src=b.asp></iframe>
框架集：<frameset><frame src=b.asp></frameset>
表單提交：<form action=b.asp><input type=submit></form>
SCRIPT引用：<script src=b.asp></script>
CSS引用：<link rel=stylesheet type=text/css href=b.asp>
XML數據島：<xml src=b.asp></xml> 而以下形式不會發送HTTP_REFERER：
script轉向：<script>location.href="b.asp"</script>
script開新窗口：<script>window.open("b.asp");</script>
META轉向：<meta http-equiv="refresh" content="0;URL=b.asp">
引入圖片：<img src=b.asp> 2 COOKIE
COOKIE是大家都非常熟悉的了，通過它可以在客戶端保存用戶狀態，即使用戶關閉瀏覽器也能繼續保存。那么客戶端與服務器端是如何交換COOKIE信息的呢？沒錯，也是通過HTTP消息頭。
首先寫一個簡單的ASP網頁：
<%
Dim i
i =? Request.Cookies("key")
Response.Write i
Response.Cookies("key") = "haha"
Response.Cookies("key").Expires = #2007-1-1#
%>
第一次訪問此網頁時，屏幕上一片白，第二次訪問時，則會顯示出“haha”。通過閱讀程序不難發現，屏幕上顯示的內容實際上是COOKIE的內容，而第一次訪問時還沒有設置COOKIE的值，所以不會有顯示，第二次顯示的是第一次設置的值。那么對應的HTTP消息頭應該是什么樣的呢？
第一次請求時沒什么不同，略過
第一次返回時消息內容多了下面這一行：
Set-Cookie: key=haha; expires=Sun, 31-Dec-2006 16:00:00 GMT; path=/
很明顯，key=haha表示鍵名為“key”的COOKIE的值為“haha”，后面是這則COOKIE的過期時間，因為我用的中文操作系統的時區是東八區，2007年1月1日0點對應的GMT時間就是2006年12月31日16點。
第二次再訪問此網頁時，發送的內容多了如下一行：
Cookie: key=haha
它的內容就是剛才設的COOKIE的內容。可見，客戶端在從服務器端得到COOKIE值以后就保存在硬盤上，再次訪問時就會把它發送到服務器。發送時并沒有發送過期時間，因為服務器對過期時間并不關心，當COOKIE過期后瀏覽器就不會再發送它了。
如果使用IE6.0瀏覽器并且禁用COOKIE功能，可以發現服務器端的set-cookie還是有的，但客戶端并不會接受它，也不會發送它。有些網站，特別是在線投票網站通過記錄COOKIE防止用戶重復投票，破解很簡單，只要用IE6瀏覽器并禁用COOKIE就可以了。也有的網站通過COOKIE值為某值來判斷用戶是否合法，這種判斷也非常容易通過手工構造HTTP消息頭來欺騙，當然用HOSTS的方式也是可以欺騙的。 3 SESSION
HTTP協議本身是無狀態的，服務器和客戶端都不保證用戶訪問期間連接會一直保持，事實上保持連接是HTTP1.1才有的新內容，當客戶端發送的消息頭中有“Connection:?Keep-Alive”時表示客戶端瀏覽器支持保持連接的工作方式，但這個連接也會在一段時間沒有請求后自動斷開，以節省服務器資源。為了在服務器端維持用戶狀態，SESSION就被發明出來了，現在各主流的動態網頁制做工具都支持SESSION，但支持的方式不完全相同，以下皆以ASP為例。
當用戶請求一個ASP網頁時，在返回的HTTP消息頭中會有一行：
Set-Cookie: ASPSESSIONIDCSQCRTBS=KOIPGIMBCOCBFMOBENDCAKDP; path=/
服務器通過COOKIE的方式告訴客戶端你的SESSIONID是多少，在這里是“KOIPGIMBCOCBFMOBENDCAKDP”，并且服務器上保留了和此SESSIONID相關的數據，當同一用戶再次發送請求時，還會把這個COOKIE再發送回去，服務器端根據此ID找到此用戶的數據，也就實現了服務器端用戶狀態的保存。所以我們用ASP編程時可以使用“session("name")=user”這樣的方式保存用戶信息。注意此COOKIE內容里并沒有過期時間，這表示這是一個當關閉瀏覽器時立即過期的COOKIE，它不會被保存到硬盤上。這種工作方式比單純用COOKIE的方式要安全很多，因為在客戶端并沒有什么能讓我們修改和欺騙的值，唯一的信息就是SESSIONID，而這個ID在瀏覽器關閉時會立即失效，除非別人能在你瀏覽網站期間或關閉瀏覽器后很短時間內知道此ID的值，才能做一些欺騙活動。因為服務器端判斷SESSION過期的方式并不是斷開連接或關閉瀏覽器，而是通過用戶手工結束SESSION或等待超時，當用戶關閉瀏覽器后的一段時間里SESSION還沒有超時，所以這時如果知道了剛才的SESSIONID，還是可以欺騙的。因此最安全的辦法還是在離開網站之前手工結束SESSION，很多網站都提供“Logout”功能，它會通過設置SESSION中的值為已退出狀態或讓SESSION立即過期從而起到安全的目的。
SESSION和COOKIE的方式各有優缺點。SESSION的優點是比較安全，不容易被欺騙，缺點是過期時間短，如果用過在超過過期時間里沒有向服務器發送任何信息，就會被認為超過過期了；COOKIE則相反，根據服務器端設置的超時時間，可以長時間保留信息，即使關機再開機也可能保留狀態，而安全性自然大打折扣。很多網站都提供兩種驗證方式相結合，如果用戶臨時用這臺電腦訪問此訪問則需要輸入用戶名和密碼，不保存COOKIE；如果用戶使用的是自己的個人電腦，則可以讓網站在自己硬盤上保留COOKIE，以后訪問時就不需要重新輸入用戶名和密碼了。 4 POST
瀏覽器訪問服務器常用的方式有GET和POST兩種，GET方式只發送HTTP消息頭，沒有消息體，也就是除了要GET的基本信息之外不向服務器提供其他信息，網頁表單（FROM）的默認提交方式就是用GET方式，它會把所有向服務器提交的信息都作為URL后面的參數，如a.asp?a=1&b=2這樣的方式。而當要提交的數據量很大，或者所提交內容不希望別人直接看到時，應該使用POST方式。POST方式提交的數據是作為HTTP消息體存在的，例如，寫一個網頁表單：
<form method=post>
<input type=text name=text1>
<input type=submit>
</form>
訪問此網頁，并在表單中填入一個“haha”，然后提交，可以看到此次提交所發送的信息如下：
POST /form.asp HTTP/1.1
Accept: */*
Referer:?http://localhost:8080/form.asp
Accept-Language: zh-cn
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; InfoPath.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Host: localhost:8080
Content-Length: 10
Connection:?Keep-Alive
Cache-Control: no-cache
Cookie: key=haha; ASPSESSIONIDCSQCRTBS=LOIPGIMBLMNOGCOBOMPJBOKP text1=haha
前面關鍵字從“GET”變為了“POST”，Content-Type變成了“application/x-www-form-urlencoded”，后面內容并無大變化，只是多了一行：Content-Length: 10，表示提交的內容的長度。空行后面是消息體，內容就是表單中所填的內容。注意此時發送的內容只是“Name=Value”的形式，表單上其他的信息不會被發送，所以想直接從服務器端取得list box中所有的list item是辦不到的，除非在提交前用一段script把所有的item內容都連在一起放到一個隱含表單域中。
如果是用表單上傳文件，情況就要復雜一些了，首先是表單聲明中要加上一句話：enctype='multipart/form-data'，表示這個表單將提交多段數據，并用HTML：input type=file來聲明一個文件提交域。
表單內容如下：
<form method=post enctype='multipart/form-data'>
<input type=text name=text1>
<input type=file name=file1>
<input type=submit>
</form>
我們為text1輸入文字：hehe，為file1選擇文件haha.txt，其內容為“ABCDEFG”，然后提交此表單。提交的完全信息為：
POST /form.asp HTTP/1.1
Accept: */*
Referer:?http://localhost:8080/form.asp
Accept-Language: zh-cn
Content-Type: multipart/form-data; boundary=---------------------------7d62bf2f9066c
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; InfoPath.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Host: localhost:8080
Content-Length: 337
Connection:?Keep-Alive
Cache-Control: no-cache
Cookie: key=haha; ASPSESSIONIDCSQCRTBS=LOIPGIMBLMNOGCOBOMPJBOKP -----------------------------7d62bf2f9066c
Content-Disposition: form-data; name="text1" hehe
-----------------------------7d62bf2f9066c
Content-Disposition: form-data; name="file1"; filename="H:/Documents and Settings/Administrator/桌面/haha.txt"
Content-Type: text/plain ABCDEFG
-----------------------------7d62bf2f9066c-- 顯然這個提交的信息要比前述的復雜很多。Content-Type變成了“multipart/form-data”，后面還多了一個boundary，此值是為了區分POST的內容的區段用的，只要在內容中遇到了此值，就表示下面要開始一個新的區段了，每個區段的內容相對獨立。如果遇到的是此值后面連著兩個減號，則表示全部內容到此結束。每個段也分為段頭和段體兩部分，用空行隔開，每段都有自己的類型和相關信息。如第一區段是text1的值，它的名稱是“text1”，值為“hehe”。第二段是文件內容，段首里表明了此文件域的名稱“file1”和此文件在用戶磁盤上的位置，后面就是文件的內容。
如果我們想要自己寫一個上傳文件組件來接收HTML表單傳送的文件數據，那么最核心的任務就是解析此數據包，從中取得需要的信息。
理解HTTP消息頭 （四）
服務器返回的消息
服務器返回的HTTP消息也分為消息頭和消息體兩部分。前面連載的第二篇里已經介紹了返回消息中常見返回代碼的含義。對于非正常的返回代碼的處理比較簡單，只要照著要求去做就好了，而對于正常的返回代碼（200），其處理方式就多種多樣了。
1 Content-Type
Content-Type是返回消息中非常重要的內容，它標識出這個返回內容的類型，其值為“主類型/子類型”的格式，例如最常見的就是text/html，它的意思是說返回的內容是文本類型，這個文本又是HTML格式的。原則上瀏覽器會根據Content-Type來決定如何顯示返回的消息體內容。常見的內容類型有：text/html?HTML文本
image/jpeg?JPG圖片
image/gif?GIF圖片
application/xml?XML文檔
audio/x-mpegurl?MP3文件列表，如果安裝了Winamp，則可以直接把它當面M3U文件來打開
更多的內容類型可以在注冊表“HKCR/MIME/Database/Content Type”下看到
對于IE6瀏覽器來說，如果Content-Type中的類型和實際的消息體類型不一致，那么它會根據內容中的類型來分析實際應該是什么類型，對于JPG、GIF等常用圖片格式都可以正確的識別出來，而不管Content-Type中寫的是什么。
如果Content-Type中指定的是瀏覽器可以直接打開的類型，那么瀏覽器就會直接打開其內容顯示出來，如果是被關聯到其它應用程序的類型，這時就要查找注冊表中關于這種類型的注冊情況，如果是允許直接打開而不需要詢問的，就會直接調出這個關聯的應用程序來打開這個文件，但如果是不允許直接打開的，就會詢問是否打開。對于沒有關聯到任何應用程序的類型，IE瀏覽器不知道它該如何打開，此時IE6就會把它當成XML來嘗試打開。
2 Content-Disposition
如果用AddHeader的方法在HTTP消息頭中加入Content-Disposition段，并指定其值為“attachment”，那么無論這個文件是何類型，瀏覽器都會提示我們下載此文件，因為此時它認為后面的消息體是一個“附件”，不需要由瀏覽器來處理了。例如，在ASP.Net中寫入如下語句：Response.AddHeader("Content-Disposition: attachment");
請求此頁面是得到的結果如：
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.1
Date: Thu, 23 Mar 2006 07:54:53 GMT
Content-Disposition: attachment
Cache-Control: private
Content-Type: text/html; charset=utf-8
……
也就是說，通過AddHeader函數可以為HTTP消息頭加入我們自定義的內容。使用這種方法可以強制讓瀏覽器提示下載文件，即使這個文件是我們已知的類型，基于是HTML網頁。如果想要讓用戶下載時提示一個默認的文件名，只需要在前面一句話后加上“filename=文件名”即可。例如：
Response.AddHeader("Content-Disposition: attachment; filename=mypage.htm");
3 Content-Type與Content-Disposition
如果把Content-Type和Content-Disposition結合在一起使用會怎么樣呢？
打開一個網頁時，瀏覽器會首先看是否有Content-Disposition: attachment這一項，如果有，無論Content-Type的值是什么，都會提示文件下載。
如果指定了filename，就會提示默認的文件名為此文件名。注意到在IE6中除了“保存”按扭外還有“打開”按扭，此時打開文件的類型是由在filename中指定的文件擴展名決定的，例如讓filename=mypic.jpg，瀏覽器就會查找默認的圖片查看器來打開此文件。
如果沒有指定filename，那么瀏覽器就根據Content-Type中的類型來決定文件的類型，例如Content-Type類型為image/gif，那么就會去查找默認的看GIF圖片的工具，并且設置此文件的名字為所請求的網頁的主名（不帶擴展名）加上對應于此文件類弄擴展名，例如請求的mypage.aspx，就會自動變成mypage.gif。如果并沒有指定Content-Type值，那么就默認它為“text/html”，并且保存的文件名就是所請求的網頁文件名。
但如果沒有指定Content-Disposition，那么就和前面關于Content-Type中所討論的情況是一樣的了。
4 Cache
返回消息中的Cache用于指定網頁緩存。我們經常可以看到這樣的情況，打開一個網頁時速度不快，但再次打開時就會快很多，原因是瀏覽器已經對此頁面進行了緩存，那么在同一瀏覽器窗口中再次打開此頁時不會重新從服務器端獲取。網頁的緩存是由HTTP消息頭中的“Cache-control”來控制的，常見的取值有private、no-cache、max-age、must-revalidate等，默認為private。其作用根據不同的重新瀏覽方式分為以下幾種情況：
（1） 打開新窗口
如果指定cache-control的值為private、no-cache、must-revalidate，那么打開新窗口訪問時都會重新訪問服務器。而如果指定了max-age值，那么在此值內的時間里就不會重新訪問服務器，例如：
Cache-control: max-age=5
表示當訪問此網頁后的5秒內再次訪問不會去服務器
（2） 在地址欄回車
如果值為private或must-revalidate（和網上說的不一樣），則只有第一次訪問時會訪問服務器，以后就不再訪問。如果值為no-cache，那么每次都會訪問。如果值為max-age，則在過期之前不會重復訪問。
（3） 按后退按扭
如果值為private、must-revalidate、max-age，則不會重訪問，而如果為no-cache，則每次都重復訪問
（4） 按刷新按扭
無論為何值，都會重復訪問
當指定Cache-control值為“no-cache”時，訪問此頁面不會在Internet臨時文章夾留下頁面備份。
另外，通過指定“Expires”值也會影響到緩存。例如，指定Expires值為一個早已過去的時間，那么訪問此網時若重復在地址欄按回車，那么每次都會重復訪問：
Expires: Fri, 31 Dec 1999 16:00:00 GMT
在ASP中，可以通過Response對象的Expires、ExpiresAbsolute屬性控制Expires值；通過Response對象的CacheControl屬性控制Cache-control的值，例如：
Response.ExpiresAbsolute = #2000-1-1#?' 指定絕對的過期時間，這個時間用的是服務器當地時間，會被自動轉換為GMT時間
Response.Expires = 20 ?' 指定相對的過期時間，以分鐘為單位，表示從當前時間起過多少分鐘過期。
Response.CacheControl = "no-cache"?
Expires值是可以通過在Internet臨時文件夾中查看臨時文件的屬性看到的，如：
發表于 @ 2008年07月14日 16:42:00?|?評論(?0?)?|?舉報|?收藏
?
總結
以上是生活随笔為你收集整理的HTTP协议的头信息详解的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Content-Type一览
- 下一篇： 网页交互