如何驗證web伺服器是否正常工作

Ⅰ 如何排除Web伺服器出現的故障

伴隨著對信息化要求的不斷提升，相信多數單位都會架設自己的Web伺服器，來在Internet網路中發布信息、宣傳自我。為了保證任何一位上網用戶都能順暢地訪問到Web伺服器中的內容，網路管理員在正式發布Web信息之前往往需要設置一下IIS伺服器，以便確保單位的Web網站可以始終如一地穩定運行。然而很多時候，我們都會遇到Web伺服器訪問失敗的故障現象，面對Web伺服器故障，我們往往會表現得手忙腳亂，根本不知道該從何處著手，來解決這些Web伺服器故障。其實，造成Web伺服器故障的因素有很多，我們需要對此進行逐一排查，才能高效解決對應的Web伺服器故障現象。Web伺服器故障現象為了充分展示單位的形象，擴大單位的知名度，單位領導要求網路管理員，立即拿出方案，組建有個性化特色的Web站點，不僅確保單位內部的員工可以通過內網正常訪問Web站點，同時還要保證外網用戶也能快速地訪問到本單位的站點內容。依照領導指示精神，網路管理員立即行動，挑選了一台運行性能非常高效的計算機作為伺服器系統，並在其中安裝、配置了Windows Server 2003系統，同時利用該系統自帶的IIS組件架設了Web伺服器;為了提高Web站點的訪問速度，網路管理員特地將Web站點所在的計算機直接連到單位千兆核心交換機上，同時將目標主機的IP地址設置成與單位普通員工所用計算機處於相同網段的地址。剛開始的時候，無論是內網用戶，還是外網用戶，所有用戶都能正常地訪問單位的Web站點。可是，沒有多長時間，單位內網用戶在訪問Web站點時，就遇到了訪問失敗的Web伺服器故障，具體表現為無論從哪一台客戶端系統出發，使用內網地址訪問單位的目標站點時，系統屏幕上都會彈出身份驗證對話框，要求單位員工必須輸入訪問賬號與密碼，可是當網路管理員嘗試以Web站點的系統管理員身份進行登錄操作時，發現始終登錄不進去;更讓人感覺到不可理解的是，網路管理員趕到Web伺服器現場，查看其安全配置時，發現目標Web站點根本就沒有啟用登錄驗證設置，那身份驗證對話框究竟是怎麼彈出來的呢?Web伺服器故障排查由於造成這類Web伺服器故障的因素比較多，我們必須要對各種可能因素進行依次排查，才能找到具體的Web伺服器故障原因，啟凡合肥網路公司分析如何採取針對性措施來快速解決故障現象：1、檢查安全登錄設置考慮到在訪問目標Web站點的時候，系統彈出了身份驗證對話框，這就意味著目標Web站點可能在安全登錄方面沒有配置正確，造成了用戶訪問Web內容時必須要輸入訪問賬號。依照這樣的分析思路，網路管理員准備先檢查一下Web伺服器的安全登錄配置參數，看看其中的設置是否正確;想到做到，網路管理員立即來到目標Web主機現場，以特權賬號登錄其中，並依次單擊「開始」/「設置」/「控制面板」選項，從彈出的系統控制面板窗口中，找到「管理工具」功能圖標，並用滑鼠雙擊該圖標選項，進入對應系統的管理工具列表窗口;接著再用滑鼠雙擊IIS功能圖標，彈出對應系統的IIS主控台窗口，從該窗口的左側列表區域，找到目標Web站點所在的計算機名稱，並用滑鼠右鍵單擊該計算機名稱，從彈出的右鍵菜單中執行「屬性」命令，彈出目標Web主機的屬性設置窗口;在該屬性設置窗口中點選「目錄安全性」選項卡，打開目錄安全性選項設置頁面;下面，在該設置頁面的「身份驗證和訪問控制」設置項右邊，單擊「編輯」按鈕，進入身份驗證和訪問控制設置對話框，網路管理員發現其中的「匿名訪問」、「集成Windows驗證」等選項都處於選中狀態，於是他嘗試著將這些參數選項取消選中，之後重新從內網的一台計算機中進行Web訪問，可是相同的故障現象仍然存在;於是，網路管理員再次選中了「匿名訪問」、「集成Windows驗證」等選項，可是讓他感覺非常失望的是，上面兩個選項無論是選中還是沒有選中，好像故障現象都存在，這就說明目標Web主機的安全登錄設置與上面的故障現象並沒有什麼關系。2、檢查上網連接設置既然登錄設置以及許可權設置，都影響不了Web伺服器訪問失敗的故障現象，那問題可能出在其他地方。考慮到單位的Web伺服器自從搭建成功後，網路管理員很少去改動它，那麼伺服器自身出現問題的可能性比較小，於是網路管理員決定從普通客戶端的網路連接設置著手，看看是否是客戶端自身原因引起的。網路管理員擔心區域網中可能存在ARP病毒，造成了普通客戶端系統訪問目標Web站點時，上網數據包被強行轉發到其他的主機上了，於是他立即登錄進入單位區域網的核心交換機後台系統，並利用系統自帶的診斷命令，對內網中每一個上網埠進行了掃描、診斷，結果發現所有上網埠的工作狀態都是正常的，而且內網網路中也不存在由ARP病毒引起的地址沖突現象，這說明內網網路中不存在ARP病毒。接著網路管理員又對幾台普通客戶端系統的網路線纜連通性進行了測試，發現它們的狀態也是正常的，並且從客戶端系統中執行ping命令，來測試目標Web站點IP地址的連通性時，也是正常的，這說明普通客戶端系統是可以正常訪問目標Web站點的。後來，網路管理員擔心客戶端系統採用了代理區域網方式上網，因為採用這種方式訪問目標Web站點時，需要先輸入代理伺服器的登錄賬號與密碼，難道我們在進行Web站點訪問操作時，系統屏幕彈出的身份驗證對話框，是針對代理伺服器的?為了排除這種因素，網路管理員立即打開客戶端系統的IE瀏覽器窗口，依次單擊其中的「工具」/「Internet選項」，打開Internet選項設置對話框，單擊其中的「連接」標簽，並在對應標簽設置頁面中，網路管理員發現本地客戶端系統並沒有啟用代理伺服器設置，這說明Web伺服器訪問失敗的故障與客戶端系統的上網連接設置沒有任何關系。3、檢查目錄訪問許可權會不會是目標Web站點所指向的主目錄，對普通用戶的訪問許可權進行了限制呢?聯想到在搭建FTP站點時，如果不對FTP站點的主目錄開放用戶訪問許可權的話，那麼普通用戶是無法通過IE瀏覽器登錄進入FTP站點的;為此，網路管理員立即打開目標Web站點的系統資源管理器窗口，從中找到對應的主目錄，用滑鼠右鍵單擊該主目錄，從彈出的快捷菜單中執行「屬性」命令，打開對應主目錄的屬性設置對話框;點選其中的「安全」選項卡，網路管理員看到其中並沒有everyone賬號的訪問許可權，難道是沒有對everyone賬號進行授權，造成了Web伺服器訪問失敗的故障現象?為了驗證這樣的猜測是否正確，網路管理員立即單擊安全選項設置頁面中的「添加」按鈕，將everyone賬號添加到賬號列表中來，同時為該賬號設置了合適的訪問許可權，最後單擊「確定」按鈕執行設置保存操作，原以為這樣的設置操作可以解決問題了，不過網路管理員再次嘗試從普通客戶端系統進行Web站點的訪問操作時，發現還是無法成功，很明顯造成上述故障現象的因素可能不是目錄訪問許可權。4、檢查授權模式配置在排除了客戶端系統的自身因素後，網路管理員再次將目光聚焦到Web伺服器身上。經過上網咨詢相關問題，網路管理員估計Windows Server 2003伺服器系統的授權模式可能被意外修改，因為伺服器授權模式要是設置不當時，很可能出現用戶無論輸入什麼登錄賬號都無效的故障現象。想到做到，網路管理員立即登錄進入Web伺服器系統，依次單擊「開始」/「設置」/「控制面板」命令，在彈出的控制面板窗口中雙擊「授權」圖標，彈出授權模式配置窗口，在這里網路管理員發現目標Web站點當前使用的是「每伺服器」授權模式;為了判斷該參數是否對Web訪問有影響，網路管理員將授權模式修改為了「每設備或用戶」選項，並且重新啟動了一下Web伺服器系統，然而這樣的調整也沒有取得任何效果，看來授權模式配置也對Web訪問操作沒有直接的影響。5、檢查其他Web服務經過上述排查，網路管理員確認Web伺服器以及客戶端系統自身狀態都是正常的，單位內網的線路也是正常的，那為什麼客戶端系統偏偏會在訪問單位Web站點時，彈出身份驗證對話框，並且無論輸入什麼用戶賬號都沒有用呢?經過仔細分析，網路管理員估計區域網中可能同時存在其他的Web服務，而其他Web服務恰好又搶用了單位Web伺服器的站點地址，最後造成了單位員工在進行Web訪問時，實際上是訪問了其他一個沒有經過正確配置的Web站點。正當網路管理員准備排查區域網中究竟是否存在其他的Web服務時，一個故障電話突然打了進來，說單位新買的列印機突然無法正常網路列印了，那麼這個故障會不會與Web伺服器訪問失敗現象有什麼必然的聯系呢?想到這一點，網路管理員立即趕到網路列印機現場，登錄進入該設備的後台管理頁面，檢查其配置參數時，發現該設備的日誌頁面提示說存在地址沖突現象，仔細一看，網路管理員發現那個沖突的地址竟然就是單位Web站點的地址，難道我們從內網客戶端系統訪問目標站點時，訪問的卻是列印機後台管理系統?既然存在地址沖突現象，網路管理員立即動手為網路列印機重新分配了一個地址，之後他再次對目標Web站點進行了訪問操作，這一次很順利地打開了對應站點內容，顯然Web伺服器故障現象已經被成功解決了。Web伺服器故障總結經過更深入地檢查，網路管理員發現列印機設備默認運行了Web服務，那樣一來列印用戶就能通過Web方式對列印設備進行遠程管理;而在默認狀態下網路列印機沒有啟用匿名訪問功能，如此一來當網路列印機使用了單位Web站點的IP地址時，上網用戶其實訪問的就是列印機後台管理頁面，而該頁面是需要進行身份驗證的，這也是普通用戶為什麼訪問目標站點時會彈出身份驗證對話框的原因了，而網路管理員由於沒有輸入網路列印機授權的用戶賬戶，才會出現無論輸入什麼用戶賬號也不能成功登錄的現象了。此次Web伺服器故障的元兇就是這個原因。回顧上面的Web伺服器故障排除過程，我們發現此次的Web伺服器故障排查其實很簡單，如果我們能夠及時注意到區域網中新增加了網路列印機的話，那麼在進行故障排查時我們或許就能注意到該變化會對Web伺服器故障造成影響了。為此，我們日後在排查網路故障之前，應該先觀察網路環境中是否存在變化，如果有變化的話，再對該變化展開針對性思考與聯想，那樣的話故障解決起來就不會繞彎子了。

Ⅱ Web測試的主要內容和測試方法有哪些

測試分類：

1、界面測試

1）給用戶的整體感：舒適感；憑感覺能找到想要找的信息；設計風格是否一致

2）各控制項的功能

2、功能測試

1）刪除/增加某一項：是否對其他項造成影響，這些影響是否都正確

2）列表默認值檢查

3）檢查按鈕功能是否正確：新建、編輯、刪除、關閉、返回、保存、導入、上一頁、下一頁、頁面跳轉、重置（常見錯誤）

4）字元串長度檢查：超出長度

5）字元類型檢查

6）標點符號檢查：空格、各種引號、Enter鍵

7）特殊字元：常見%、「、」

8）中文字元：是否亂碼

9）檢查信息完整：查看信息，查看所填信息是否完整更新；更新信息，更新信息與添加信息是否一致

10）信息重復：需唯一信息處，比如重復的名字或ID、重名是否區分大小寫、加空格

11）檢查刪除功能：不選擇任何信息，按Delete，看如何處理；選擇一個或多個進行刪除；多頁選、翻頁選刪除；刪除是否有提示

12）檢查添加和修改是否一致：添加必填項，修改也該必填盯備纖；添加為什麼類型，修改也該什麼類型

13）檢查修改重名：修改時把不能重名的項改為已存在的內容

14）重復提交表單：一條已經成功提交的記錄，返回後再提交

15）檢查多次使用返回鍵：返回滾配到原來頁面，重復多次

16）搜索檢查：存在或不存在內容，看搜索結果是凱仿否正確；多個搜索條件，同時輸入合理和不合理條件；特殊字元

17）輸入信息的位置

18）上傳下載文件檢查：功能是否實現，

上傳：上傳文件是否能打開、格式要求、系統是否有解釋信息、將不能上傳的文件格式修改後綴為可上傳的文件格式；

下載：下載是否能打開、保存、格式要求

19）必填項檢查：必填項未填寫；是否有提示，如加*；對必填項提示返回後，焦點是否自動定位到必填項

20）快捷鍵檢查：是否支持快捷鍵Ctrl+C、Ctrl+V、backspace；對不允許做輸入的欄位（如：下拉選項），對快捷方式是否也做了限制

21）Enter鍵檢查：輸入結束後按Enter鍵，系統如何處理

22）刷新鍵檢查：按瀏覽器刷新鍵如何處理

23）回退鍵檢查：按瀏覽器回退鍵如何處理

24）空格檢查：輸入項輸入一個或多個空格

25）輸入法半形全形檢查：比如，浮點型，輸入全形小數點「。」或「. 」，如4. 5；全形空格

26）密碼檢查：輸入加密方式的極限字元；密碼盡可能長

27）用戶檢查：不同種類管理員用戶的不同許可權，是否可以互相刪除、管理、編輯；一般用戶的許可權；注銷功能，老用戶注銷再注冊，是否為新用戶

28）系統數據檢查：數據隨業務過程、狀態的變化保持正確，不能因為某個過程出現垃圾數據，也不能因為某個過程而丟失數據。

29）系統可恢復性檢查：以各種方式把系統搞癱，測試系統是否可以迅速恢復

30）確認提示檢查：系統更新、刪除操作：是否有提示、取消操作；提示是否准確；事前、事後提示

31）數據注入檢查：對資料庫注入，特殊字元，對SQL語句進行破壞

32）時間日期檢查：時間、日期、時間驗證：日期范圍是否符合實際業務；對於不符合實際業務的日期是否有限制

33）多瀏覽器驗證

3、性能測試

1）壓力測試：實際破壞一個Web應用系統，測試系統的反應，測試系統的限制和故障恢復能力

2）負載測試：在某一負載級別上的性能，包括某個時刻同時訪問Web的用戶數量、在線數據處理的數量

3）強度測試：測試對象在性能行為異常或極端條件下（如資源減少或用戶過多）的可接受性，以此驗證系統軟硬體水平

4）資料庫容量測試：通過存儲過程往資料庫表中插入一定數量的數據，看是否能及時顯示

5）預期指標的性能測試：在需求分析和設計階段會提出一些性能指標，對於預先確定的性能要求要首先進行測試

6）獨立業務性能測試：對核心業務模塊做用戶並發測試，包括同一時刻進行完全一樣的操作、同一時刻使用完全一樣的功能

7）組合業務性能測試：模擬多用戶的不同操作，最接近實際用戶使用情況，按用戶實際的實際使用人數比例來模擬各個模塊的組合並發情況

8）疲勞強度性能測試：系統穩定運行情況下，以一定負載壓力來長時間運行系統的測試

9）網路性能測試：准確展示帶寬、延遲、負載、埠的變化是如何影響用戶的相應時間的

10）大數據量性能測試：實時大數據量，模擬用戶工作時的實時大數據量；極限狀態下的測試，系統使用一段時間，積累一段數據量時能否正常運行，以及對前面兩種進行結合

11）伺服器性能測試：在進行用戶並發性能測試、疲勞強度、大數據量性能測試時，完成對伺服器性能的監控，並進行評估

12）一些特殊的測試：配置測試、內存泄漏的一些特殊測試

4、可用性測試(介面測試）

1）整體界面測試

2）多媒體測試

3）導航測試

5、客戶端兼容性

平台測試：windows；unix；macintosh；linux

瀏覽器測試：不同廠商的瀏覽器對java、Javascript、ActiveX、plug-ins或不同的HTML的規格

不同的支持；框架和層次結構在不同瀏覽器也不同的顯示

6、安全性

安全性測試要求：

1）能夠對密碼試探工具進行防範

2）能夠防範對Cookie攻擊的常用手段

3）敏感數據保證不用明文傳輸

4）能防範通過文件名猜測和查看html文件內容獲取重要信息

5）能保證在網站收到工具後在給定時間內恢復，重要數據丟失不超過1小時

web的性能測試工具：

隨著Web2.0技術的迅速發展，許多公司都開發了一些基於Web的網站服務，通常在設計開發Web應用系統的時候很難模擬出大量用戶同時訪問系統的實際情況。

因此，當Web網站遇到訪問高峰時，容易發生伺服器響應速度變慢甚至服務中斷。

為了避免這種情況，需要一種能夠真實模擬大量用戶訪問Web應用系統的性能測試工具進行壓力測試，來測試靜態HTML頁面的響應時間，甚至測試動態網頁（包括ASP、PHP、JSP等）的響應時間，為伺服器的性能優化和調整提供數據依據。

1、企業級自動化測試工具WinRunner

MercuryInteractive公司的WinRunner是一種企業級的功能測試工具，用於檢測應用程序是否能夠達到預期的功能及正常運行。

2、工業標准級負載測試工具Loadrunner

LoadRunner是一種預測系統行為和性能的負載測試工具

3、全球測試管理系統testdirector

TestDirector是業界第一個基於Web的測試管理系統，它可以在您公司內部或外部進行全球范圍內測試的管理。

4、功能測試工具RationalRobot

IBMRationalRobot是業界最頂尖的功能測試工具，它甚至可以在測試人員學習高級腳本技術之前幫助其進行成功的測試。

它集成在測試人員的桌面IBMRationalTestManager上，在這里測試人員可以計劃、組織、執行、管理和報告所有測試活動，包括手動測試報告。

這種測試和管理的雙重功能是自動化測試的理想開始。

5、單元測試工具xUnit系列

目前的最流行的單元測試工具是xUnit系列框架，常用的根據語言不同分為JUnit（java），CppUnit（C++），DUnit（Delphi），NUnit（.net），PhpUnit（Php）等等。

該測試框架的第一個和最傑出的應用就是由ErichGamma（《設計模式》的作者）和KentBeck（XP（ExtremeProgramming）的創始人）提供的開放源代碼的JUnit.

6、功能測試工具SilkTest

BorlandSilkTest2006屬於軟體功能測試工具，是Borland公司所提出軟體質量管理解決方案的套件之一。

這個工具採用精靈設定與自動化執行測試，無論是程序設計新手或資深的專家都能快速建立功能測試，並分析功能錯誤。

7、性能測試工具WAS

是由微軟的網站測試人員所開發，專門用來進行實際網站壓力測試的一套工具。

透過這套功能強大的壓力測試工具，您可以使用少量的Client端計算機模擬大量用戶上線對網站服務所可能造成的影響。

8、自動化白盒測試工具Jtest

Jtest是parasoft公司推出的一款針對java語言的自動化白盒測試工具，它通過自動實現java的單元測試和代碼標准校驗，來提高代碼的可靠性。

parasoft同時出品的還有C++test，是一款C/C++白盒測試工具。

9、功能和性能測試的工具JMeter

JMeter是Apache組織的開放源代碼項目，它是功能和性能測試的工具，100%的用java實現。

10、性能測試和分析工具WEBLOAD

webload是RadView公司推出的一個性能測試和分析工具，它讓web應用程序開發者自動執行壓力測試；webload通過模擬真實用戶的操作，生成壓力負載來測試web的性能。

(2)如何驗證web伺服器是否正常工作擴展閱讀：

漏洞測試

企業網站做的越來越復雜、功能越來越強。不過這些都不是憑空而來的，是通過代碼堆積起來的。如果這個代碼只供企業內部使用，那麼不會帶來多大的安全隱患。

但是如果放在互聯網上使用的話，則這些為實現特定功能的代碼就有可能成為攻擊者的目標。

天眼舉一個簡單的例子。在網頁中可以嵌入SQL代碼。而攻擊者就可以利用這些SQL代碼來發動攻擊，來獲取管理員的密碼等等破壞性的動作。

有時候訪問某些網站還需要有某些特定的控制項。用戶在安裝這些控制項時，其實就有可能在安裝一個木馬（這可能訪問者與被訪問者都沒有意識到）。

為此在為網站某個特定功能編寫代碼時，就要主動出擊。從編碼的設計到編寫、到測試，都需要認識到是否存在著安全的漏洞。

天眼在日常過程中，在這方面對於員工提出了很高的要求。各個員工必須對自己所開發的功能負責。

已知的病毒、木馬不能夠在所開發的插件中有機可乘。通過這層層把關，就可以提高代碼編寫的安全性。

Ⅲ 如何通過HTTP狀態判斷伺服器運營狀態

HTTP狀態碼(HTTP Status Code)是用以表示網頁伺服器HTTP響應狀態的3位數字代碼。它由 RFC 2616 規范定義的，並得到RFC 2518、RFC 2817、RFC 2295、RFC 2774、RFC 4918等規范擴展。

所有狀態碼的第一個數字代表了響應的五種狀態之一。

1xx 消息

這一類型的狀態碼，代表請求已被接受，需要繼續處理。這類響應是臨時響應，只包含狀態行和某些可選的響應頭信息，並以空行結束。由於 HTTP/1.0 協議中沒有定義任何 1xx 狀態碼，所以除非在某些試驗條件下，伺服器禁止向此類客戶端發送 1xx 響應。

100 Continue

客戶端應當繼續發送請求。這個臨時響應是用來通知客戶端它的部分請求已經被伺服器接收，且仍未被拒絕。客戶端應當繼續發送請求的剩餘部分，或者如果請求已經完成，忽略這個響應。伺服器必須在請求完成後向客戶端發送一個最終響應。

101 Switching Protocols

伺服器已經理解了客戶端的請求，並將通過 Upgrade 消息頭通知客戶端採用不同的協議來完成這個請求。在發送完這個響應最後的空行後，伺服器將會切換到在 Upgrade 消息頭中定義的那些協議。

只有在切換新的協議更有好處的時候才應該採取類似措施。例如，切換到新的 HTTP 版本比舊版本更有優勢，或者切換到一個實時且同步的協議以傳送利用此類特性的資源。

102 Processing

由WebDAV(RFC 2518)擴展的狀態碼，代表處理將被繼續執行。

2xx 成功

這一類型的狀態碼，代表請求已成功被伺服器接收、理解、並接受。

200 OK

請求已成功，請求所希望的響應頭或數據體將隨此響應返回。

201 Created

請求已經被實現，而且有一個新的資源已經依據請求的需要而建立，且其 URI 已經隨 Location 頭信息返回。假如需要的資源無法及時建立的話，應當返回 '202 Accepted'。

202 Accepted

伺服器已接受請求，但尚未處理。正如它可能被拒絕一樣，最終該請求可能會也可能不會被執行。在非同步操作的場合下，沒有比發送這個狀態碼更方便的做法了。

返回202狀態碼的響應的目的是允許伺服器接受其他過程的請求(例如某個每天只執行一次的基於批處理的操作)，而不必讓客戶端一直保持與伺服器的連接直到批處理操作全部完成。在接受請求處理並返回202狀態碼的響應應當在返回的實體中包含一些指示處理當前狀態的信息，以及指向處理狀態監視器或狀態預測的指針，以便用戶能夠估計操作是否已經完成。

203 Non-Authoritative Information

伺服器已成功處理了請求，但返回的實體頭部元信息不是在原始伺服器上有效的確定集合，而是來自本地或者第三方的拷貝。當前的信息可能是原始版本的子集或者超集。例如，包含資源的元數據可能導致原始伺服器知道元信息的超級。使用此狀態碼不是必須的，而且只有在響應不使用此狀態碼便會返回200 OK的情況下才是合適的。

204 No Content

伺服器成功處理了請求，但不需要返回任何實體內容，並且希望返回更新了的元信息。響應可能通過實體頭部的形式，返回新的或更新後的元信息。如果存在這些頭部信息，則應當與所請求的變數相呼應。

如果客戶端是瀏覽器的話，那麼用戶瀏覽器應保留發送了該請求的頁面，而不產生任何文檔視圖上的變化，即使按照規范新的或更新後的元信息應當被應用到用戶瀏覽器活動視圖中的文檔。

由於204響應被禁止包含任何消息體，因此它始終以消息頭後的第一個空行結尾。

205 Reset Content

伺服器成功處理了請求，且沒有返回任何內容。但是與204響應不同，返回此狀態碼的響應要求請求者重置文檔視圖。該響應主要是被用於接受用戶輸入後，立即重置表單，以便用戶能夠輕松地開始另一次輸入。

與204響應一樣，該響應也被禁止包含任何消息體，且以消息頭後的第一個空行結束。

206 Partial Content

伺服器已經成功處理了部分 GET 請求。類似於 FlashGet 或者迅雷這類的 HTTP 下載工具都是使用此類響應實現斷點續傳或者將一個大文檔分解為多個下載段同時下載。

該請求必須包含 Range 頭信息來指示客戶端希望得到的內容範圍，並且可能包含 If-Range 來作為請求條件。

響應必須包含如下的頭部域：

Content-Range 用以指示本次響應中返回的內容的范圍;如果是 Content-Type 為 multipart/byteranges 的多段下載，則每一 multipart 段中都應包含 Content-Range 域用以指示本段的內容範圍。假如響應中包含 Content-Length，那麼它的數值必須匹配它返回的內容範圍的真實位元組數。

Date

ETag 和/或 Content-Location，假如同樣的請求本應該返回200響應。

Expires, Cache-Control，和/或 Vary，假如其值可能與之前相同變數的其他響應對應的值不同的話。

假如本響應請求使用了 If-Range 強緩存驗證，那麼本次響應不應該包含其他實體頭;假如本響應的請求使用了 If-Range 弱緩存驗證，那麼本次響應禁止包含其他實體頭;這避免了緩存的實體內容和更新了的實體頭信息之間的不一致。否則，本響應就應當包含所有本應該返回200響 應中應當返回的所有實體頭部域。

假如 ETag 或 Last-Modified 頭部不能精確匹配的話，則客戶端緩存應禁止將206響應返回的內容與之前任何緩存過的內容組合在一起。

任何不支持 Range 以及 Content-Range 頭的緩存都禁止緩存206響應返回的內容。

207 Multi-Status

由WebDAV(RFC 2518)擴展的狀態碼，代表之後的消息體將是一個XML消息，並且可能依照之前子請求數量的不同，包含一系列獨立的響應代碼。

3xx 重定向

這類狀態碼代表需要客戶端採取進一步的操作才能完成請求。通常，這些狀態碼用來重定向，後續的請求地址(重定向目標)在本次響應的 Location 域中指明。

當且僅當後續的請求所使用的方法是 GET 或者 HEAD 時，用戶瀏覽器才可以在沒有用戶介入的情況下自動提交所需要的後續請求。客戶端應當自動監測無限循環重定向(例如：A->A，或者A->B->C->A)，因為這會導致伺服器和客戶端大量不必要的資源消耗。按照 HTTP/1.0 版規范的建議，瀏覽器不應自動訪問超過5次的重定向。

300 Multiple Choices

被請求的資源有一系列可供選擇的回饋信息，每個都有自己特定的地址和瀏覽器驅動的商議信息。用戶或瀏覽器能夠自行選擇一個首選的地址進行重定向。

除非這是一個 HEAD 請求，否則該響應應當包括一個資源特性及地址的列表的實體，以便用戶或瀏覽器從中選擇最合適的重定向地址。這個實體的格式由 Content-Type 定義的格式所決定。瀏覽器可能根據響應的格式以及瀏覽器自身能力，自動作出最合適的選擇。當然，RFC 2616規范並沒有規定這樣的自動選擇該如何進行。

如果伺服器本身已經有了首選的回饋選擇，那麼在 Location 中應當指明這個回饋的 URI;瀏覽器可能會將這個 Location 值作為自動重定向的地址。此外，除非額外指定，否則這個響應也是可緩存的。

301 Moved Permanently

被請求的資源已永久移動到新位置，並且將來任何對此資源的引用都應該使用本響應返回的若干個 URI 之一。如果可能，擁有鏈接編輯功能的客戶端應當自動把請求的地址修改為從伺服器反饋回來的地址。除非額外指定，否則這個響應也是可緩存的。

新的永久性的 URI 應當在響應的 Location 域中返回。除非這是一個 HEAD 請求，否則響應的實體中應當包含指向新的 URI 的超鏈接及簡短說明。

如果這不是一個 GET 或者 HEAD 請求，因此瀏覽器禁止自動進行重定向，除非得到用戶的確認，因為請求的條件可能因此發生變化。

注意：對於某些使用 HTTP/1.0 協議的瀏覽器，當它們發送的 POST 請求得到了一個301響應的話，接下來的重定向請求將會變成 GET 方式。

302 Found

請求的資源現在臨時從不同的 URI 響應請求。由於這樣的重定向是臨時的，客戶端應當繼續向原有地址發送以後的請求。只有在Cache-Control或Expires中進行了指定的情況下，這個響應才是可緩存的。

新的臨時性的 URI 應當在響應的 Location 域中返回。除非這是一個 HEAD 請求，否則響應的實體中應當包含指向新的 URI 的超鏈接及簡短說明。

如果這不是一個 GET 或者 HEAD 請求，那麼瀏覽器禁止自動進行重定向，除非得到用戶的確認，因為請求的條件可能因此發生變化。

注意：雖然RFC 1945和RFC 2068規范不允許客戶端在重定向時改變請求的方法，但是很多現存的瀏覽器將302響應視作為303響應，並且使用 GET 方式訪問在 Location 中規定的 URI，而無視原先請求的方法。狀態碼303和307被添加了進來，用以明確伺服器期待客戶端進行何種反應。

303 See Other

對應當前請求的響應可以在另一個 URI 上被找到，而且客戶端應當採用 GET 的方式訪問那個資源。這個方法的存在主要是為了允許由腳本激活的POST請求輸出重定向到一個新的資源。這個新的 URI 不是原始資源的替代引用。同時，303響應禁止被緩存。當然，第二個請求(重定向)可能被緩存。

新的 URI 應當在響應的 Location 域中返回。除非這是一個 HEAD 請求，否則響應的實體中應當包含指向新的 URI 的超鏈接及簡短說明。

注意：許多 HTTP/1.1 版以前的 瀏覽器不能正確理解303狀態。如果需要考慮與這些瀏覽器之間的互動，302狀態碼應該可以勝任，因為大多數的瀏覽器處理302響應時的方式恰恰就是上述規范要求客戶端處理303響應時應當做的。

304 Not Modified

如果客戶端發送了一個帶條件的 GET 請求且該請求已被允許，而文檔的內容(自上次訪問以來或者根據請求的條件)並沒有改變，則伺服器應當返回這個狀態碼。304響應禁止包含消息體，因此始終以消息頭後的第一個空行結尾。

該響應必須包含以下的頭信息：

Date，除非這個伺服器沒有時鍾。假如沒有時鍾的伺服器也遵守這些規則，那麼代理伺服器以及客戶端可以自行將 Date 欄位添加到接收到的響應頭中去(正如RFC 2068中規定的一樣)，緩存機制將會正常工作。

ETag 和/或 Content-Location，假如同樣的請求本應返回200響應。

Expires, Cache-Control，和/或 Vary，假如其值可能與之前相同變數的其他響應對應的值不同的話。

假如本響應請求使用了強緩存驗證，那麼本次響應不應該包含其他實體頭;否則(例如，某個帶條件的 GET 請求使用了弱緩存驗證)，本次響應禁止包含其他實體頭;這避免了緩存了的實體內容和更新了的實體頭信息之間的不一致。

假如某個304響應指明了當前某個實體沒有緩存，那麼緩存系統必須忽視這個響應，並且重復發送不包含限制條件的請求。

假如接收到一個要求更新某個緩存條目的304響應，那麼緩存系統必須更新整個條目以反映所有在響應中被更新的欄位的值。

305 Use Proxy

被請求的資源必須通過指定的代理才能被訪問。 Location 域中將給出指定的代理所在的 URI 信息，接收者需要重復發送一個單獨的請求，通過這個代理才能訪問相應資源。只有原始伺服器才能建立305響應。

注意：RFC 2068中沒有明確305響應是為了重定向一個單獨的請求，而且只能被原始伺服器建立。忽視這些限制可能導致嚴重的安全後果。

306 Switch Proxy

在最新版的規范中，306狀態碼已經不再被使用。

307 Temporary Redirect

請求的資源現在臨時從不同的 URI 響應請求。由於這樣的重定向是臨時的，客戶端應當繼續向原有地址發送以後的請求。只有在Cache-Control或Expires中進行了指定的情況下，這個響應才是可緩存的。

新的臨時性的 URI 應當在響應的 Location 域中返回。除非這是一個 HEAD 請求，否則響應的實體中應當包含指向新的 URI 的超鏈接及簡短說明。因為部分瀏覽器不能識別307響應，因此需要添加上述必要信息以便用戶能夠理解並向新的 URI 發出訪問請求。

如果這不是一個 GET 或者 HEAD 請求，那麼瀏覽器禁止自動進行重定向，除非得到用戶的確認，因為請求的條件可能因此發生變化。