轉 http協議中有關http頭的技術資料-

一、基礎篇
　　 HTTP（HyperTextTransferProtocol）是超文字傳輸協議的縮寫，它用於傳送WWW方式的資料，關於HTTP協議的詳細內容請參考RFC2616。HTTP協議採用了請求/響應模型。客戶端向伺服器傳送一個請求，請求頭包含請求的方法、URI、協議版本、以及包含請求修飾符、客戶資訊和內容的類似於MIME的訊息結構。伺服器以一個狀態行作為響應，相應的內容包括訊息協議的版本，成功或者錯誤編碼加上包含伺服器資訊、實體元資訊以及可能的實體內容。[@more@]

通常HTTP訊息包括客戶機向伺服器的請求訊息和伺服器向客戶機的響應訊息。這兩種型別的訊息由一個起始行，一個或者多個頭域，一個只是頭域結束的空行和可選的訊息體組成。HTTP的頭域包括通用頭，請求頭，響應頭和實體頭四個部分。每個頭域由一個域名，冒號（:）和域值三部分組成。域名是大小寫無關的，域值前可以新增任何數量的空格符，頭域可以被擴充套件為多行，在每行開始處，使用至少一個空格或製表符。
1、通用頭域
通用頭域包含請求和響應訊息都支援的頭域，通用頭域包含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相同。
2、請求訊息
請求訊息的第一行為下面的格式：
Method　SP　Request-URI　SP　HTTP-Version　CRLF
Method 表示對於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
Host:download.microtool.de
Accept:*/*
Pragma:no-cache
Cache-Control:no-cache
Referer:
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頭域的內容包含發出請求的使用者資訊。
3、響應訊息
響應訊息的第一行為下面的格式：
HTTP-Version　SP　Status-Code　SP　Reason-Phrase　CRLF
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響應頭包含處理請求的原始伺服器的軟體資訊。此域能包含多個產品標識和註釋，產品標識一般按照重要性排序。
4、實體資訊
請求訊息和響應訊息都可以包含實體資訊，實體資訊一般由實體頭域和實體組成。實體頭域包含關於實體的原資訊，實體頭包括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-unit　SP　first-byte-pos - last-byte-pos/entity-legth
例如，傳送頭500個位元組次欄位的形式：Content-Range:bytes0-499/1234如果一個http訊息包含此節（例如，對範圍請求的響應或對一系列範圍的重疊請求），Content-Range表示傳送的範圍，Content-Length表示實際傳送的位元組數。
Last-modified實體頭
Last-modified實體頭指定伺服器上儲存內容的最後修訂時間。
5、 HTTP 頭參考（microsoft）
HTTP 請求和 HTTP 響應都使用頭髮送有關 HTTP
訊息的資訊。頭由一系列行組成，每行都包含名稱，然後依次是冒號、空格、值。欄位可按任何順序排列。某些頭欄位既能用於請求頭也能用於響應頭，而另一些頭欄位只能用於其中之一。
許多請求頭欄位都允許客戶端在值部分指定多個可接受的選項，有時甚至可以對這些選項的首選項進行排名。多個項以逗號分隔。例如，客戶端可以傳送包含"Content-Encoding:
gzip, compress,"的請求頭，表示可以接受各種壓縮型別。如果伺服器的響應正文使用 gzip
編碼，其響應頭中將包含"Content-Encoding: gzip"。
有些欄位可以在單個頭中出現多次。例如，頭可以有多個"Warning"欄位。
下表列出了 HTTP 1.1 頭欄位。注意：有些頭欄位是 MIME 欄位。MIME 欄位在 Internet Engineering
Task Force (IETF) 文件 RFC 2045 中進行了定義，但也可用於 HTTP 1.1 協議。有關 MIME 和 HTTP
1.1 規範的詳細資訊，請參閱 IEIF 頁。
一般頭欄位
一般頭欄位可用於請求訊息和響應訊息。
　名稱　　　　　　　　　　示例值
Cache-Control　 "max-age=10"
Connection　　　　"close"
Date　　　　　　　　　　"Tue, 11 Jul 2000 18:23:51 GMT"
Pragma　　　　　　　 "no-cache"
Trailer　　　　　　　　 "Date"
Transfer-Encoding "chunked"
Upgrade　　　　　　 "SHTTP/1.3"
Via　　　　　　　　　　　 "HTTP/1.1 Proxy1, HTTP/1.1 Proxy2"
Warning　　　　　　　"112 Disconnected Operation"
請求頭欄位
請求頭欄位僅用於請求訊息。
　　 名稱　　　　　　　　　　　　 示例值
Accept　　　　　　　　　　 "text/html, image/*"
Accept-Charset　　　"iso8859-5"
Accept-Encoding 　"gzip, compress"
Accept-Language　"en, fr"
Authorization　　　　 [credentials]
Content-Encoding　"gzip"
Expect　　　　　　　　　　 "100-continue"
From　　　　　　　　　　　 "user@microsoft.com"
Host　　　　　　　　　　　　"
If-Match　　　　　　　　　"entity_tag001"
If-Modified-Since "Tue, 11 Jul 2000 18:23:51 GMT"
If-None-Match　　　 "entity_tag001"
If-Range　　　　　　　　 "entity_tag001" or "Tue, 11 Jul 2000 18:23:51 GMT"
If-Unmodified-Since "Tue, 11 Jul 2000 18:23:51 GMT"
Max-Forwards　　　　"3"
Proxy-Authorization [credentials]
Range　　　　　　 "bytes=100-599"
Referer　　　　　 "
TE　　　　　　　　　　"trailers"
User-Agent　　 "Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)"
>>請求頭欄位的具體含義
Accept：瀏覽器可接受的MIME型別。
Accept-Charset：瀏覽器可接受的字符集。
Accept-Encoding：瀏覽器能夠進行解碼的資料編碼方式，比如gzip。
Accept-Language：瀏覽器所希望的語言種類，當伺服器能夠提供一種以上的語言版本時要用到。
Authorization：授權資訊，通常出現在對伺服器傳送的WWW-Authenticate頭的應答中。
Connection：表示是否需要持久連線。如果Servlet看到這裡的值為"Keep-Alive"，或者看到請求使用的是HTTP
1.1 （HTTP 1.1預設進行持久連線），它就可以利用持久連線的優點，當頁面包含多個元素時（例如Applet，圖片），顯著地減少下載所需要的時間。要實現這一點， Servlet需要在應答中傳送一個Content-Length頭，最簡單的實現方法是：先把內容寫入ByteArrayOutputStream，然後在正式寫出內容之前計算它的大小。
Content-Length：表示請求訊息正文的長度。
Cookie：設定cookie,這是最重要的請求頭資訊之一
From：請求傳送者的email地址，由一些特殊的Web客戶程式使用，瀏覽器不會用到它。
Host：初始URL中的主機和埠。
If-Modified-Since：只有當所請求的內容在指定的日期之後又經過修改才返回它，否則返回304"Not Modified"應答。
Pragma：指定"no-cache"值表示伺服器必須返回一個重新整理後的文件，即使它是代理伺服器而且已經有了頁面的本地複製。
Referer：包含一個URL，使用者從該URL代表的頁面出發訪問當前請求的頁面。
User-Agent：瀏覽器型別，如果Servlet返回的內容與瀏覽器型別有關則該值非常有用。
UA-Pixels，UA-Color，UA-OS，UA-CPU：由某些版本的IE瀏覽器所傳送的非標準的請求頭，表示螢幕大小、顏色深度、作業系統和CPU型別。
響應頭欄位
響應頭欄位僅用於響應訊息。
　 名稱　　　　　　　　　 示例值
Accept-Ranges　　"none"
Age　　　　　　　　　　　　"2147483648(2^31)"
ETag　　　　　　　　　　　"b38b9-17dd-367c5dcd"
Last-Modified　　　 "Tue, 11 Jul 2000 18:23:51 GMT"
Location　　　　　　　　"
Proxy-Authenticate [challenge]
Retry-After　　　　　 "Tue, 11 Jul 2000 18:23:51 GMT" or "60"
Server　　　　　　　　　"Microsoft-IIS/5.0"
Vary　　　　　　　　　　　 "Date"
WWW-Authenticate [challenge]
實體頭欄位
實體頭欄位可以用於請求訊息或響應訊息。實體頭欄位中包含訊息實體正文的有關資訊，如使用的編碼格式。
　　 名稱　　　　　　　　　　　 示例值
Allow　　　　　　　　　　　　　　"GET, HEAD"
Content-Encoding　　 "gzip"
Content-Language　　"en"
Content-Length　　　　 "8445"
Content-Location　　　"
Content-MD5　　　　　　 [md5-digest]
Content-Range　　　　 "bytes 2543-4532/7898"
Content-Type　　　　　　"text/html"
Expires　　　　　　　　　　　"Tue, 11 Jul 2000 18:23:51 GMT"
Last-Modified　　　　　 "Tue, 11 Jul 2000 18:23:51 GMT"
>>實體頭欄位的具體含義
Allow 伺服器支援哪些請求方法（如GET、POST等）。
Content-Encoding
文件的編碼（Encode）方法。只有在解碼之後才可以得到Content-Type頭指定的內容型別。利用gzip壓縮文件能夠顯著地減少HTML文件的下載時間。Java的GZIPOutputStream可以很方便地進行gzip壓縮，但只有Unix上的Netscape和Windows上的IE
4、IE 5才支援它。
Content-Length 表示內容長度。只有當瀏覽器使用持久HTTP連線時才需要這個資料。
Content-Type 表示後面的文件屬於什麼MIME型別。Servlet預設為text/plain，但通常需要顯式地指定為text/html。
Date 當前的GMT時間。你可以用setDateHeader來設定這個頭以避免轉換時間格式的麻煩。
Expires 應該在什麼時候認為文件已經過期，從而不再快取它？
Last-Modified 文件的最後改動時間。客戶可以透過If-Modified-Since請求頭提供一個日期，該請求將被視為一個條件GET，只有改動時間遲於指定時間的文件才會返回，否則返回一個304（Not
Modified）狀態。
Location 表示客戶應當到哪裡去提取文件。Location通常不是直接設定的，而是透過HttpServletResponse的sendRedirect方法，該方法同時設定狀態程式碼為302。
Refresh 表示瀏覽器應該在多少時間之後重新整理文件，以秒計。除了重新整理當前文件之外，你還可以透過setHeader("Refresh",
"5; URL=)讓瀏覽器讀取指定的頁面。
注意這種功能通常是透過設定HTML頁面HEAD區的＜META HTTP-EQUIV="Refresh"
CONTENT="5;URL=＞實現，這是因為，自動重新整理或重定向對於那些不能使用CGI或Servlet的HTML編寫者十分重要。但是，對於Servlet來說，直接設定Refresh頭更加方便。
注意Refresh的意義是"N秒之後重新整理本頁面或訪問指定頁面"，而不是"每隔N秒重新整理本頁面或訪問指定頁面"。因此，連續重新整理要求每次都傳送一個Refresh頭，而傳送204狀態程式碼則可以阻止瀏覽器繼續重新整理，不管是使用Refresh頭還是＜META
HTTP-EQUIV="Refresh" ...＞。
注意Refresh頭不屬於HTTP 1.1正式規範的一部分，而是一個擴充套件，但Netscape和IE都支援它。
請求頭示例
以下是 HTTP 請求的簡單示例。
GET /articles/news/today.asp HTTP/1.1
Accept: */*
Accept-Language: en-us
Connection: Keep-Alive
Host: localhost
Referer:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
Accept-Encoding: gzip, deflate
該請求具有請求行，其中包括方法 (GET)、資源路徑 (/articles/news/today.asp) 和 HTTP 版本
(HTTP/1.1)。由於該請求沒有正文，故所有請求行後面的內容都是頭的一部分。緊接著頭之後是一個空行，表示頭已結束。
響應頭示例
Web 伺服器可以透過多種方式響應前一個請求。假設檔案是可以訪問的，並且使用者具有檢視該檔案的許可權，則響應類似於：
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Thu, 13 Jul 2000 05:46:53 GMT
Content-Length: 2291
Content-Type: text/html
Set-Cookie: ASPSESSIONIDQQGGGNCG=LKLDFFKCINFLDMFHCBCBMFLJ; path=/
Cache-control: private
...
響應的第一行稱為狀態行。它包含響應所用的 HTTP 版本、狀態編碼 (200)
和原因短語。示例中包含一個頭，其中具有五個欄位，接著是一個空行（回車和換行符），然後是響應正文的頭兩行。
有關HTTP頭完整、詳細的說明，請參見的HTTP規範。
附錄:HTTP協議狀態碼的含義
　　狀態程式碼 狀態資訊 含義
100 Continue 初始的請求已經接受，客戶應當繼續傳送請求的其餘部分。（HTTP 1.1新）
101 Switching Protocols 伺服器將遵從客戶的請求轉換到另外一種協議（HTTP 1.1新
200 OK 一切正常，對GET和POST請求的應答文件跟在後面。
201 Created 伺服器已經建立了文件，Location頭給出了它的URL。
202 Accepted 已經接受請求，但處理尚未完成。
203 Non-Authoritative Information 文件已經正常地返回，但一些應答頭可能不正確，因為使用的是文件的複製（HTTP 1.1新）。
204 No Content 沒有新文件，瀏覽器應該繼續顯示原來的文件。
205 Reset Content 沒有新的內容，但瀏覽器應該重置它所顯示的內容。用來強制瀏覽器清除表單輸入內容（HTTP 1.1新）。
206 Partial Content 客戶傳送了一個帶有Range頭的GET請求，伺服器完成了它（HTTP 1.1新）。
300 Multiple Choices
客戶請求的文件可以在多個位置找到，這些位置已經在返回的文件內列出。如果伺服器要提出優先選擇，則應該在Location應答頭指明。
301 Moved Permanently 客戶請求的文件在其他地方，新的URL在Location頭中給出，瀏覽器應該自動地訪問新的URL。
302 Found 類似於301，但新的URL應該被視為臨時性的替代，而不是永久性的。注意，在HTTP1.0中對應的狀態資訊是"Moved
Temporatily"，出現該狀態程式碼時，瀏覽器能夠自動訪問新的URL，因此它是一個很有用的狀態程式碼。注意這個狀態程式碼有時候可以和301替換使用。例如，如果瀏覽器錯誤地請求~user（缺少了後面的斜槓），有的伺服器返回301，有的則返回302。嚴格地說，我們只能假定只有當原來的請求是 GET時瀏覽器才會自動重定向。請參見307。
303 See Other 類似於301/302，不同之處在於，如果原來的請求是POST，Location頭指定的重定向目標文件應該透過GET提取（HTTP
1.1新）。
304 Not Modified
客戶端有緩衝的文件併發出了一個條件性的請求（一般是提供If-Modified-Since頭表示客戶只想比指定日期更新的文件）。伺服器告訴客戶，原來緩衝的文件還可以繼續使用。
305 Use Proxy 客戶請求的文件應該透過Location頭所指明的代理伺服器提取（HTTP 1.1新）。
307 Temporary Redirect
和302（Found）相同。許多瀏覽器會錯誤地響應302應答進行重定向，即使原來的請求是POST，即使它實際上只能在POST請求的應答是303時才能重定向。由於這個原因，HTTP
1.1新增了307，以便更加清除地區分幾個狀態程式碼：當出現303應答時，瀏覽器可以跟隨重定向的GET和POST請求；如果是307應答，則瀏覽器只能跟隨對GET請求的重定向。（HTTP
1.1新）
400 Bad Request 請求出現語法錯誤。
401 Unauthorized
客戶試圖未經授權訪問受密碼保護的頁面。應答中會包含一個WWW-Authenticate頭，瀏覽器據此顯示使用者名稱字/密碼對話方塊，然後在填寫合適的Authorization頭後再次發出請求。
403 Forbidden 資源不可用。伺服器理解客戶的請求，但拒絕處理它。通常由於伺服器上檔案或目錄的許可權設定導致。
404 Not Found 無法找到指定位置的資源。這也是一個常用的應答，
405 Method Not Allowed
請求方法（GET、POST、HEAD、DELETE、PUT、TRACE等）對指定的資源不適用。（HTTP 1.1新）
406 Not Acceptable 指定的資源已經找到，但它的MIME型別和客戶在Accpet頭中所指定的不相容（HTTP 1.1新）。
407 Proxy Authentication Required 類似於401，表示客戶必須先經過代理伺服器的授權。（HTTP 1.1新）
408 Request Timeout 在伺服器許可的等待時間內，客戶一直沒有發出任何請求。客戶可以在以後重複同一請求。（HTTP 1.1新）
409 Conflict 通常和PUT請求有關。由於請求和資源的當前狀態相沖突，因此請求不能成功。（HTTP 1.1新）
410 Gone 所請求的文件已經不再可用，而且伺服器不知道應該重定向到哪一個地址。它和404的不同在於，返回407表示文件永久地離開了指定的位置，而404表示由於未知的原因文件不可用。（HTTP
1.1新）
411 Length Required 伺服器不能處理請求，除非客戶傳送一個Content-Length頭。（HTTP 1.1新）
412 Precondition Failed 請求頭中指定的一些前提條件失敗（HTTP 1.1新）。
413 Request Entity Too Large
目標文件的大小超過伺服器當前願意處理的大小。如果伺服器認為自己能夠稍後再處理該請求，則應該提供一個Retry-After頭（HTTP
1.1新）。
414 Request URI Too Long URI太長（HTTP 1.1新）。
416 Requested Range Not Satisfiable 伺服器不能滿足客戶在請求中指定的Range頭。（HTTP 1.1新）
500 Internal Server Error 伺服器遇到了意料不到的情況，不能完成客戶的請求。
501 Not Implemented 伺服器不支援實現請求所需要的功能。例如，客戶發出了一個伺服器不支援的PUT請求。
502 Bad Gateway 伺服器作為閘道器或者代理時，為了完成請求訪問下一個伺服器，但該伺服器返回了非法的應答。
503 Service Unavailable 伺服器由於維護或者負載過重未能應答。
504 Gateway Timeout 由作為代理或閘道器的伺服器使用，表示不能及時地從遠端伺服器獲得應答。（HTTP 1.1新）
505 HTTP Version Not Supported 伺服器不支援請求中所指明的HTTP版本。（HTTP 1.1新）

part of
RFC 2616 Fielding, et al.

Status Code Definitions

Each Status-Code is described below, including a description of which method(s) it can follow and any metainformation required in the response.

Informational 1xx

This class of status code indicates a provisional response, consisting only of the Status-Line and optional headers, and is terminated by an empty line. There are no required headers for this class of status code. Since HTTP/1.0 did not define any 1xx status codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client except under experimental conditions.

A client MUST be prepared to accept one or more 1xx status responses prior to a regular response, even if the client does not expect a 100 (Continue) status message. Unexpected 1xx status responses MAY be ignored by a user agent.

Proxies MUST forward 1xx responses, unless the connection between the proxy and its client has been closed, or unless the proxy itself requested the generation of the 1xx response. (For example, if a

proxy adds a "Expect: 100-continue" field when it forwards a request, then it need not forward the corresponding 100 (Continue) response(s).)

100 Continue

The client SHOULD continue with its request. This interim response is used to inform the client that the initial part of the request has been received and has not yet been rejected by the server. The client SHOULD continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The server MUST send a final response after the request has been completed. See section for detailed discussion of the use and handling of this status code.

101 Switching Protocols

The server understands and is willing to comply with the client's request, via the Upgrade message header field (section 14.42), for a change in the application protocol being used on this connection. The server will switch protocols to those defined by the response's Upgrade header field immediately after the empty line which terminates the 101 response.

The protocol SHOULD be switched only when it is advantageous to do so. For example, switching to a newer version of HTTP is advantageous over older versions, and switching to a real-time, synchronous protocol might be advantageous when delivering resources that use such features.

Successful 2xx

This class of status code indicates that the client's request was successfully received, understood, and accepted.

200 OK

The request has succeeded. The information returned with the response is dependent on the method used in the request, for example:

GET an entity corresponding to the requested resource is sent in the response;

HEAD the entity-header fields corresponding to the requested resource are sent in the response without any message-body;

POST an entity describing or containing the result of the action;

TRACE an entity containing the request message as received by the end server.

201 Created

The request has been fulfilled and resulted in a new resource being created. The newly created resource can be referenced by the URI(s) returned in the entity of the response, with the most specific URI for the resource given by a Location header field. The response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. The origin server MUST create the resource before returning the 201 status code. If the action cannot be carried out immediately, the server SHOULD respond with 202 (Accepted) response instead.

A 201 response MAY contain an ETag response header field indicating the current value of the entity tag for the requested variant just created, see section .

202 Accepted

The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. There is no facility for re-sending a status code from an asynchronous operation such as this.

The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the server persist until the process is completed. The entity returned with this response SHOULD include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled.

203 Non-Authoritative Information

The returned metainformation in the entity-header is not the definitive set as available from the origin server, but is gathered from a local or a third-party copy. The set presented MAY be a subset or superset of the original version. For example, including local annotation information about the resource might result in a superset of the metainformation known by the origin server. Use of this response code is not required and is only appropriate when the response would otherwise be 200 (OK).

204 No Content

The server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation. The response MAY include new or updated metainformation in the form of entity-headers, which if present SHOULD be associated with the requested variant.

If the client is a user agent, it SHOULD NOT change its document view from that which caused the request to be sent. This response is primarily intended to allow input for actions to take place without causing a change to the user agent's active document view, although any new or updated metainformation SHOULD be applied to the document currently in the user agent's active view.

The 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields.

205 Reset Content

The server has fulfilled the request and the user agent SHOULD reset the document view which caused the request to be sent. This response is primarily intended to allow input for actions to take place via user input, followed by a clearing of the form in which the input is given so that the user can easily initiate another input action. The response MUST NOT include an entity.

206 Partial Content

The server has fulfilled the partial GET request for the resource. The request MUST have included a Range header field (section 14.35) indicating the desired range, and MAY have included an If-Range header field (section ) to make the request conditional.

The response MUST include the following header fields:

      - Either a Content-Range header field (section 14.16) indicating
        the range included with this response, or a multipart/byteranges
        Content-Type including Content-Range fields for each part. If a
        Content-Length header field is present in the response, its
        value MUST match the actual number of OCTETs transmitted in the
        message-body.

      - Date

      - ETag and/or Content-Location, if the header would have been sent
        in a 200 response to the same request

      - Expires, Cache-Control, and/or Vary, if the field-value might
        differ from that sent in any previous response for the same
        variant

If the 206 response is the result of an If-Range request that used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. If the response is the result of an If-Range request that used a weak validator, the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers. Otherwise, the response MUST include all of the entity-headers that would have been returned with a 200 (OK) response to the same request.

A cache MUST NOT combine a 206 response with other previously cached content if the ETag or Last-Modified headers do not match exactly, see .

A cache that does not support the Range and Content-Range headers MUST NOT cache 206 (Partial) responses.

Redirection 3xx

This class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request. The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. A client SHOULD detect infinite redirection loops, since such loops generate network traffic for each redirection.

      Note: previous versions of this specification recommended a
      maximum of five redirections. Content developers should be aware
      that there might be clients that implement such a fixed
      limitation.

300 Multiple Choices

The requested resource corresponds to any one of a set of representations, each with its own specific location, and agent- driven negotiation information (section 12) is being provided so that the user (or user agent) can select a preferred representation and redirect its request to that location.

Unless it was a HEAD request, the response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content- Type header field. Depending upon the format and the capabilities of

the user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection.

If the server has a preferred choice of representation, it SHOULD include the specific URI for that representation in the Location field; user agents MAY use the Location field value for automatic redirection. This response is cacheable unless indicated otherwise.

301 Moved Permanently

The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.

The new permanent URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

If the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

      Note: When automatically redirecting a POST request after
      receiving a 301 status code, some existing HTTP/1.0 user agents
      will erroneously change it into a GET request.

302 Found

The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.

The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

      Note: RFC 1945 and RFC 2068 specify that the client is not allowed
      to change the method on the redirected request.  However, most
      existing user agent implementations treat 302 as if it were a 303
      response, performing a GET on the Location field-value regardless
      of the original request method. The status codes 303 and 307 have
      been added for servers that wish to make unambiguously clear which
      kind of reaction is expected of the client.

303 See Other

The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. The new URI is not a substitute reference for the originally requested resource. The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable.

The different URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

      Note: Many pre-HTTP/1.1 user agents do not understand the 303
      status. When interoperability with such clients is a concern, the
      302 status code may be used instead, since most user agents react
      to a 302 response as described here for 303.

304 Not Modified

If the client has performed a conditional GET request and access is allowed, but the document has not been modified, the server SHOULD respond with this status code. The 304 response MUST NOT contain a message-body, and thus is always terminated by the first empty line after the header fields.

The response MUST include the following header fields:

      - Date, unless its omission is required by section 14.18.1

If a clockless origin server obeys these rules, and proxies and clients add their own Date to any response received without one (as already specified by [RFC 2068], section ), caches will operate correctly.

      - ETag and/or Content-Location, if the header would have been sent
        in a 200 response to the same request

      - Expires, Cache-Control, and/or Vary, if the field-value might
        differ from that sent in any previous response for the same
        variant

If the conditional GET used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers.

If a 304 response indicates an entity not currently cached, then the cache MUST disregard the response and repeat the request without the conditional.

If a cache uses a received 304 response to update a cache entry, the cache MUST update the entry to reflect any new field values given in the response.

305 Use Proxy

The requested resource MUST be accessed through the proxy given by the Location field. The Location field gives the URI of the proxy. The recipient is expected to repeat this single request via the proxy. 305 responses MUST only be generated by origin servers.

      Note: RFC 2068 was not clear that 305 was intended to redirect a
      single request, and to be generated by origin servers only.  Not
      observing these limitations has significant security consequences.

306 (Unused)

The 306 status code was used in a previous version of the specification, is no longer used, and the code is reserved.

307 Temporary Redirect

The requested resource resides temporarily under a different URI. Since the redirection MAY be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.

The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s) , since many pre-HTTP/1.1 user agents do not understand the 307 status. Therefore, the note SHOULD contain the information necessary for a user to repeat the original request on the new URI.

If the 307 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

Client Error 4xx

The 4xx class of status code is intended for cases in which the client seems to have erred. Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. User agents SHOULD display any included entity to the user.

If the client is sending data, a server implementation using TCP SHOULD be careful to ensure that the client acknowledges receipt of the packet(s) containing the response, before the server closes the input connection. If the client continues sending data to the server after the close, the server's TCP stack will send a reset packet to the client, which may erase the client's unacknowledged input buffers before they can be read and interpreted by the HTTP application.

400 Bad Request

The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.

401 Unauthorized

The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section ). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity might include relevant diagnostic information. HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" .

402 Payment Required

This code is reserved for future use.

403 Forbidden

The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.

404 Not Found

The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.

405 Method Not Allowed

The method specified in the Request-Line is not allowed for the resource identified by the Request-URI. The response MUST include an Allow header containing a list of valid methods for the requested resource.

406 Not Acceptable

The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request.

Unless it was a HEAD request, the response SHOULD include an entity containing a list of available entity characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection.

      Note: HTTP/1.1 servers are allowed to return responses which are
      not acceptable according to the accept headers sent in the
      request. In some cases, this may even be preferable to sending a
      406 response. User agents are encouraged to inspect the headers of
      an incoming response to determine if it is acceptable.

If the response could be unacceptable, a user agent SHOULD temporarily stop receipt of more data and query the user for a decision on further actions.

407 Proxy Authentication Required

This code is similar to 401 (Unauthorized), but indicates that the client must first authenticate itself with the proxy. The proxy MUST return a Proxy-Authenticate header field (section ) containing a challenge applicable to the proxy for the requested resource. The client MAY repeat the request with a suitable Proxy-Authorization header field (section ). HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" .

408 Request Timeout

The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time.

409 Conflict

The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response body SHOULD include enough

information for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required.

Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the entity being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might use the 409 response to indicate that it can't complete the request. In this case, the response entity would likely contain a list of the differences between the two versions in a format defined by the response Content-Type.

410 Gone

The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent. Clients with link editing capabilities SHOULD delete references to the Request-URI after user approval. If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) SHOULD be used instead. This response is cacheable unless indicated otherwise.

The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event is common for limited-time, promotional services and for resources belonging to individuals no longer working at the server's site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time -- that is left