如何验证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 请求，那么浏览器禁止自动进行重定向，除非得到用户的确认，因为请求的条件可能因此发生变化。