HTTP ── HyperText Transfer Protocol 超文本传输协议

google

HTTP ── HyperText Transfer Protocol 超文本传输协议

HTTP 是 HyperText Transfer Protocol 的简写，中文译为 “超文本传输协议”。HTTP 是互联网上应用最为广泛的一种网络协议。所有的 WWW 文件都必须遵守此标准。

HTTP 的设计目的是为提供一种发布和接收 HTML 页面的方法。HTTP 协议是从 WWW 服务器传输超文本到本地浏览器的传输协议。

HTTP 可使浏览器更高效，使网络传输减少。它不仅保证计算机正确快速地传输超文本文档，还确定传输文档中的哪一部分，以及哪部分内容首先显示（如：文本先于图形）等。

HTTP 是客户端浏览器或其他程序与 Web 服务器之间的应用层通信协议。在 Internet 的 Web 服务器上存放的都是超文本信息，客户机需要通过 HTTP 协议传输所要访问的超文本信息。HTTP包含命令和传输信息，不仅可用于 Web 访问，也可用于其他 因特网/内联网 应用系统之间的通信，从而实现各应用资源超媒体访问的集成。

1960年美国人 Ted Nelson 构思了一种通过计算机处理文本信息的方法，并称之为超文本（hypertext），这成为了 HTTP 超文本传输协议标准架构的发展基础。Ted Nelson 组织协调万维网协会（World Wide Web Consortium）和互联网工程工作小组（Internet Engineering Task Force）共同合作研究，最终发布了一系列的 RFC，其中著名的 RFC 2616 定义了 HTTP 1.1。

通过 HTTP 或 HTTPS 协议请求的资源由统一资源标示符（Uniform Resource Identifiers）（或更准确一些，URLs）标识。

我们在浏览器的地址栏里输入的网站地址 URL，像每家每户的一个门牌地址，每个网页也有一个 Internet 地址。当你在浏览器地址框中输入一个 URL 或是单击一个超级链接时，URL 就确定了要浏览的地址。浏览器通过超文本传输协议 (HTTP)，将 Web 服务器上站点的网页代码提取出来，并翻译成漂亮的网页。

HTTP 是一个客户端和服务器端，请求和应答的标准（TCP）。客户端是终端用户，服务器端是网站。通过使用 Web 浏览器、网络爬虫或其它工具，客户端发起一个到服务器指定端口（默认端口为 80）的 HTTP 请求。我们称这个客户端叫用户代理（user agent）。应答服务器上存储着一些资源，比如 HTML 文件和图像。我们称这个应答服务器为源服务器（origin server）。

在用户代理和源服务器中间，可能存在 HTTP 和其他几种网络协议及多个中间层；譬如代理、网关、或隧道（tunnels）。尽管 TCP/IP 协议是互联网上最流行的应用，但 HTTP 协议并没有规定，必须使用 TCP/IP 和（基于）TCP/IP 支持的层。 事实上，HTTP 可在任何其他互联网协议上，或在其他网络上实现。HTTP 只假定（其下层协议提供）可靠的传输，任何能提供这种保证的协议都可被其使用。

通常，由 HTTP 客户端发起一个请求，建立一个到服务器指定端口（默认是 80 端口）的 TCP 连接。HTTP 服务器则在那个端口监听客户端发送过来的请求。一旦收到请求，服务器会（向客户端）发回一个状态行（譬如："HTTP/1.1 200 OK"）和（响应）消息；消息的消息体可能是请求文件、错误消息、或其它一些信息。HTTP 使用 TCP 而不是 UDP 的原因在于（打开）一个网页必须传送很多数据，TCP 协议能提供传输控制，按顺序组织数据和错误纠正。

运作方式

在 WWW 中，“客户”与“服务器”是一个相对概念，只存在于一个特定的连接期间，即：某个连接中的客户在另一个连接中可能作为服务器。基于 HTTP 协议的 客户/服务器 模式的信息交换过程，分 4 步：建立连接、发送请求信息、发送响应信息、关闭连接。

HTTP 协议是基于 请求/响应 模式的。客户机与服务器建立连接后，发送一个请求给服务器，请求格式为：统一资源标识符、协议版本号、后边是 MIME 信息，包括请求修饰符、客户机信息和可能的内容。服务器接到请求后，给予相应的响应信息，其格式为：一个状态行包括信息的协议版本号、一个成功或错误的代码，后边是 MIME 信息包括服务器信息、实体信息和可能的内容。

简单说，就是任何服务器除了包括 HTML 文件以外，还有一个 HTTP 驻留程序，用于响应用户请求。你的浏览器是 HTTP 客户，向服务器发送请求，当浏览器中输入了一个开始文件或点击了一个超级链接时，浏览器就会向服务器发送 HTTP 请求，此请求被送往由 IP 地址指定的 URL。驻留程序接收到请求，在进行必要的操作后回送所要求的文件。在这一过程中，在网络上发送和接收的数据已被分成一个或多个数据包（packet），每个数据包，包括：要传送的数据；控制信息：告诉网络怎样处理数据包；TCP/IP：决定了每个数据包的格式。如事先不告诉你，你可能不知道信息被分成用于传输和再重新组合起来的许多小块。

许多 HTTP 通讯是由一个用户代理初始化的，并包括一个在源服务器上申请资源的请求。最简单的情况可能是在用户代理 (UA) 和源服务器 (O) 之间通过一个单独的连接来完成。

当一个或多个中介出现在 请求/响应 链中时，情况会变得复杂一些。中介有 3 种：代理 (Proxy)、网关 (Gateway)、通道 (Tunnel)。

代理根据 URI 的绝对格式来接受请求，重写全部或部分消息，通过 URI 的标识把已格式化过的请求发送到服务器。

网关是一个接收代理，作为某些其它服务器的上层，如果必须的话，可把请求翻译给下层的服务器协议。

通道作为不改变消息的两个连接之间的中继点。当通讯需要通过一个中介 (例如：防火墙等) 或是中介不能识别消息内容时，经常会使用通道。

基本工作原理

一次 HTTP 操作可称为一个事务，其工作过程分为 4 步：

01、客户机与服务器建立连接

只要单击某个超级链接，HTTP的工作就开始了。

02、建立连接后，客户机发送一个请求给服务器

请求方式的格式为：统一资源标识符（URL）、协议版本号，后边是MIME 信息，包括请求修饰符、客户机信息和可能的内容。

03、服务器接到请求后，给予相应的响应信息

其格式为一状态行，包括信息的协议版本号、一个成功或错误代码，后边是 MIME 信息，包括服务器信息、实体信息和可能的内容。

04、客户端接收服务器返回的信息

通过浏览器显示在用户显示屏上，然后客户机与服务器断开连接。

如在以上过程中的某一步出现错误，那么，产生错误的信息将返回到客户端，由显示屏输出。对于用户来说，这些过程是由 HTTP 自己完成的，用户只要用鼠标点击，等待信息显示就可以了。

许多 HTTP 通讯是由一个用户代理初始化的，并包括一个在源服务器上申请资源的请求。最简单的情况可能是在用户代理和服务器之间，通过一个单独的连接来完成。在 Internet上，HTTP 通讯通常发生在 TCP/IP 连接之上。缺省端口是 TCP 80，但其它的端口也是可用的。但这并不预示着 HTTP 协议在 Internet 或其它网络的其它协议之上才能完成。HTTP 只预示着一个可靠的传输。

这个过程就像打电话订货一样，打电话给商家，告诉他我们需要什么规格的商品，然后商家再告诉我们什么商品有货，什么商品缺货。这些，我们是通过电话线用电话联系（HTTP 是通过 TCP/IP），当然我们也可通过传真，只要商家那边也有传真。

报文格式

HTTP 报文由从客户机到服务器的请求，和从服务器到客户机的响应构成。

请求报文格式如下：

请求行 － 通用信息头 － 请求头 － 实体头 － 报文主体

请求行以方法字段开始，后面分别是 URL 字段和 HTTP 协议版本字段，并以 CRLF 结尾。

SP 是分隔符。

除了在最后的 CRLF 序列中 CF 和 LF 是必需的之外，其他都可以不要。

有关通用信息头，请求头和实体头方面的具体内容可参照相关文件。

应答报文格式如下：

状态行 － 通用信息头 － 响应头 － 实体头 － 报文主体

状态码由 3 位数字组成，表示请求是否被理解或被满足。原因分析是对原文状态码作简短描述，状态码用于支持自动操作，而原因分析则用来供用户使用。客户机无需用来检查或显示语法。有关通用信息头，响应头和实体头方面的具体内容可参照相关文件。

协议基础

HTTP 用于传送 WWW 形式的数据，关于 HTTP 协议的详细内容请参考 RFC2616。HTTP 协议采用请求/响应模型。客户端向服务器发送一个请求，请求头包含请求方法、URL、协议版本、以及包含请求修饰符、客户信息和内容类似 MIME 的消息结构。服务器以一状态行作为响应，响应的内容包括消息协议的版本，成功或错误编码加上包含服务器信息、实体元信息以及可能的实体内容。

通常，HTTP 消息包括客户机向服务器的请求消息和服务器向客户机的响应消息。这 2 种类型的消息由一个起始行、一个或多个头域、一个指示头域结束的空行和可选的消息体组成。

HTTP 的头域包括通用头、请求头、响应头和实体头 4 个部分。每个头域由一个域名、冒号（:）和域值三部分组成。域名是大小写无关的，域值前可添加任何数量的空格符，头域可被扩展为多行，在每行开始处，使用至少一个空格或制表符。

01、通用头域

通用头域包含请求和响应消息都支持的头域，通用头域包含 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 消息的值，那么客户机可接收，超出超时期指定值之内的响应消息。

HTTP Keep-Alive

Keep-Alive 功能使客户端到服务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive 功能避免了建立或重新建立连接。市场上的大部分 Web 服务器，包括 iPlanet、IIS 和 Apache，都支持 HTTP Keep-Alive。对于提供静态内容的网站来说，这个功能非常很有用。但是，对于负担较重的网站来说，这就存在另外一个问题：虽然为客户保留打开的连接有一定的好处，但它同样影响了性能，因为在处理暂停期间，本来可以释放的资源仍旧被占用。当 Web 服务器和应用服务器在同一台机器上运行时，Keep- Alive 功能对资源利用的影响尤其突出。

KeepAliveTime 值控制 TCP/IP 尝试验证空闲连接是否完好的频率。如果这段时间内没有活动，则会发送保持活动信号。如网络工作正常，且接收方是活动的，它就会响应。如需对丢失接收方敏感，换句话说，需更快地发现丢失了接收方，请考虑减小这个值。如长期不活动的空闲连接出现次数较多，而丢失接收方的情况出现较少，您可能会要提高该值以减少开销。缺省情况下，如果空闲连接 7200000 毫秒（2 小时）内没有活动，Windows 就会发送保持活动的消息。通常，1800000 毫秒是首选值，从而，一半的已关闭连接会在 30 分钟内被检测到。 KeepAliveInterval 值定义了如未从接收方收到保持活动消息的响应，TCP/IP 重复发送保持活动信号的频率。当连续发送保持活动信号、但未收到响应的次数超出TcpMaxDataRetransmissions 的值时，会放弃该连接。如期望较长的响应时间，您可能需要提高该值以减少开销。如需要减少花在验证接收方是否已丢失上的时间，请考虑减小该值或 TcpMaxDataRetransmissions 值。缺省情况下，在未收到响应而重新发送保持活动的消息之前，Windows 会等待 1000 毫秒（1 秒）。 KeepAliveTime 根据需要设置就行，比如 10 分钟，注意要转换成 MS。 XXX 代表这个间隔值的大小。

Date 头域

Date 头域表示消息发送的时间，时间的描述格式由 RFC 822 定义。例如，Date:Mon,31Dec200104:25:57GMT。Date 描述的时间表示世界标准时，换算成本地时间，需要知道用户所在的时区。

Pragma 头域

Pragma 头域用来包含实现特定的指令，最常用的是 Pragma:no-cache。在 HTTP 1.1 协议中，它的含义和 Cache-Control:no-cache 相同。

02、请求消息

请求消息的第一行为下面的格式：

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。对请求头域的扩展要求通讯双方都支持，如果存在不支持的请求头域，一般将会作为实体头域处理。

典型的请求消息：

Host: download.*******.de

Accept: */*

Pragma: no-cache

Cache-Control: no-cache

User-Agent: Mozilla/4.04[en](Win95;I;Nav)

Range: bytes=554554-

上例第一行表示 HTTP 客户端（可能是浏览器、下载程序），通过 GET 方法获得指定 URL 下的文件。Pragma: no-cache、Cache-Control: no-cache 表示通用头部分，Host: download.*******.de、Accept: */*、User-Agent: Mozilla/4.04[en](Win95;I;Nav)、Range: bytes=554554- 表示请求头域信息。

Host 头域

Host头域指定请求资源的 Intenet主机和端口号，必须表示请求 URL 的原始服务器或网关的位置。HTTP 1.1 请求必须包含主机头域，否则系统会以 400 状态码返回。

Referer 头域

HTTP Referer 是 HTTP (HyperText Transfer Protocol 超文本传输协议) 请求消息 header 的一部分，当浏览器向 web 服务器发送请求时，一般会带上 Referer，告诉服务器我是从哪个页面链接过来的，服务器籍此获得一些信息再进行处理。

HTTP Referer 头允许客户端指定请求 URL 的源资源地址，这允许服务器生成回退链表，可用来登陆、优化 cache 等。也允许废除或错误的连接，由于维护目的可被追踪。如请求的 URL 没有自己的 URL 地址，Referer 就不会被发送。如指定的是部分 URL 地址，则此地址应该是一个相对地址。

HTTP Referer 用来表示从哪儿连结到目前网页，采用的格式是 URL。换句话说，借由 Referer，目前网页可检查访客是从哪里来的，这也常被用来对付伪造的跨网站请求。

Dereferer 则是将 Referer 所带资讯剥离，因此，网站将无法识别访客从何而来。

当访客访问网页时，Referer 或 Referring page 是前一网页的 URL。如是图片的话，通常指的就是图片所在的网页。在通过网页浏览器把请求消息送往网页服务器时，Referer 会被包含在 HTTP 请求方法中。

许多网站会把 Referer 记录下来，以便追踪使用者的动态，大部分的统计分析软件都能处理这种资讯。但 Referer 资讯可能存在隐私权问题，部分网页浏览器允许使用者不送出这种资讯。某些代理服务器和防火墙也可把 Referer 资讯过滤掉，以避免外部知道非公开的网站位置。

缺少 Referer资讯或可能造成某些问题：某些服务器会因为缺少正确 Referer资讯而进行阻挡，以避免未经授权的图片使用 (盗图) 或是其他对服务器有影响的行为。针对这样的阻挡，有些代理服务器软件则提供了针对特定网站送出假 Referer 资讯的功能。

譬如：从主页链接到一个朋友那里，他的服务器就能从 HTTP Referer 中统计出每天有多少用户点击我主页上的链接访问他的网站。

Referer 的正确英语拼法是 referrer。由于早期 HTTP 规范的拼写错误，为保持向后兼容就将错就错了。其它网络技术规范企图修正此问题，使用正确拼法，所以目前其拼法并不统一。

HTTP Referer 非常简单，比较多的是用于页面统计、资源防盗链等；但还是有一点值得注意：Referer 是不安全的，通过客户端设置可改变Request 中的值，所以，请尽量不要用来作为进行安全验证等。

Range 头域

Range 头域可请求实体的一个或多个子范围。譬如：

Range 头域范围一览表

#	值	说明	备注
01	bytes=0-499	表示头 500 个字节
02	bytes=500-999	表示第二个 500 字节
03	bytes=-500	表示最后 500 个字节
04	bytes=500-	表示 500 字节以后的范围
05	bytes=0-0,-1	第一个和最后一个字节
06	bytes=500-600,601-999	同时指定几个范围

但服务器可忽略此请求头，如无条件 GET 包含 Range 请求头，响应会以状态码 206（PartialContent）返回而不是以 200（OK）。

User-Agent 头域

User-Agent头域的内容包含发出请求的用户信息。

User-Agent 英文简称 UA，中文译为 “用户代理”。User-Agent 是 HTTP 协议的一部分，属于请求头域。

User-Agent 是向访问网站提供所用浏览器类型及版本、操作系统及版本、CPU 类型、浏览器渲染引擎、浏览器语言、浏览器插件、等信息的一特殊字符串头标识。

User-Agent 字符串在每次浏览器进行 HTTP 请求时，会被发送到服务器！

某些网站常通过判断 User-Agent 来给不同操作系统、不同浏览器发送不同页面；因此，可能造成某些页面无法在某个浏览器中正常显示，但通过伪装 User-Agent 可绕过此种检测。

03、响应消息

响应消息的第一行为下面的格式：

HTTP-VersionSPStatus-CodeSPReason-PhraseCRLF

HTTP-Version 表示支持的 HTTP 版本，譬如为 HTTP 1.1。

Status-Code 是一个3 位数字的结果代码。

Reason-Phrase 给 Status-Code 提供一个简单的文本描述。

Status-Code 主要用于机器自动识别，Reason-Phrase 主要用于帮助用户理解。Status-Code 的第 1 位数字定义响应的类别，后 2 位数字没有分类的作用。第一个数字可能取 5 个不同的值：

Status-Code 第 1 位数字取值一览表

#	值	说明	备注
01	1xx	信息响应类，表示接收到请求并继续处理
02	2xx	处理成功响应类，表示动作被成功接收、理解和接受
03	3xx	重定向响应类，为完成指定的动作，必须接受进一步处理
04	4xx	客户端错误，客户请求包含语法错误或不能正确执行
05	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:bytes55******/40279980

第一行 HTTP/1.0200OK 表示 HTTP 服务端响应一个 GET 方法。Server:Apache/1.3.14(Unix) 表示响应头域信息，Date:Mon,31Dec200104:25:57GMT 表示通用头部分，Content-type:text/html、Last-modified:Tue,17Apr200106:46:28GMT、Etag:"a030f020ac7c01:1e9f" 、Content-length:39725426、Content-range:bytes55******/40279980 表示实体头域信息。

Location 响应头

Location 响应头用于重定向接收者到一个新 URI 地址。

Server 响应头

Server 响应头包含处理请求的原始服务器软件信息。此域可包含多个产品标识和注释，产品标识一般按重要性排序。

04、实体信息

请求消息和响应消息都可包含实体信息，实体信息一般由实体头域和实体组成。实体头域包含关于实体的原信息，实体头包括 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 实体头

Last-modified实体头可指定服务器上保存内容的最后修订时间。

状态消息

1xx:信息

消息	描述
100 Continue	服务器仅接收到部分请求，但是一旦服务器并没有拒绝该请求，客户端应该继续发送其余的请求。
101 Switching Protocols	服务器转换协议：服务器将遵从客户的请求转换到另外一种协议。

2xx:成功

消息	描述
200 OK	请求成功（其后是对GET和POST请求的应答文档。）
201 Created	请求被创建完成，同时新的资源被创建。
202 Accepted	供处理的请求已被接受，但是处理未完成。
203 Non-authoritative Information	文档已经正常地返回，但一些应答头可能不正确，因为使用的是文档的拷贝。
204 No Content	没有新文档。浏览器应该继续显示原来的文档。如果用户定期地刷新页面，而Servlet可以确定用户文档足够新，这个状态代码是很有用的。
205 Reset Content	没有新文档。但浏览器应该重置它所显示的内容。用来强制浏览器清除表单输入内容。
206 Partial Content	客户发送了一个带有Range头的GET请求，服务器完成了它。

3xx:重定向

消息	描述
300 Multiple Choices	多重选择。链接列表。用户可以选择某链接到达目的地。最多允许五个地址。
301 MovedPermanently	所请求的页面已经转移至新的url。
302 Found	所请求的页面已经临时转移至新的url。
303 See Other	所请求的页面可在别的url下被找到。
304 Not Modified	未按预期修改文档。客户端有缓冲的文档并发出了一个条件性的请求（一般是提供If-Modified-Since头表示客户只想比指定日期更新的文档）。服务器告诉客户，原来缓冲的文档还可以继续使用。
305 Use Proxy	客户请求的文档应该通过Location头所指明的代理服务器提取。
306 Unused	此代码被用于前一版本。目前已不再使用，但是代码依然被保留。
307 Temporary Redirect	被请求的页面已经临时移至新的url。

4xx:客户端错误

消息	描述
400 Bad Request	服务器未能理解请求。
401 Unauthorized	被请求的页面需要用户名和密码。
401.1	登录失败。
401.2	服务器配置导致登录失败。
401.3	由于 ACL 对资源的限制而未获得授权。
401.4	筛选器授权失败。
401.5	ISAPI/CGI 应用程序授权失败。
401.7	访问被 Web 服务器上的 URL 授权策略拒绝。这个错误代码为 IIS 6.0 所专用。
402 Payment Required	此代码尚无法使用。
403 Forbidden	对被请求页面的访问被禁止。
403.1	执行访问被禁止。
403.2	读访问被禁止。
403.3	写访问被禁止。
403.4	要求 SSL。
403.5	要求 SSL 128。
403.6	IP 地址被拒绝。
403.7	要求客户端证书。
403.8	站点访问被拒绝。
403.9	用户数过多。
403.10	配置无效。
403.11	密码更改。
403.12	拒绝访问映射表。
403.13	客户端证书被吊销。
403.14	拒绝目录列表。
403.15	超出客户端访问许可。
403.16	客户端证书不受信任或无效。
403.17	客户端证书已过期或尚未生效。
403.18	在当前的应用程序池中不能执行所请求的 URL。这个错误代码为 IIS 6.0 所专用。
403.19	不能为这个应用程序池中的客户端执行 CGI。这个错误代码为 IIS 6.0 所专用。
403.20	Passport 登录失败。这个错误代码为 IIS 6.0 所专用。
404 Not Found	服务器无法找到被请求的页面。
404.0	（无）–没有找到文件或目录。
404.1	无法在所请求的端口上访问 Web 站点。
404.2	Web 服务扩展锁定策略阻止本请求。
404.3	MIME 映射策略阻止本请求。
405 Method Not Allowed	请求中指定的方法不被允许。
406 Not Acceptable	服务器生成的响应无法被客户端所接受。
407 Proxy Authentication Required	用户必须首先使用代理服务器进行验证，这样请求才会被处理。
408 Request Timeout	请求超出了服务器的等待时间。
409 Conflict	由于冲突，请求无法被完成。
410 Gone	被请求的页面不可用。
411 Length Required	"Content-Length" 未被定义。如果无此内容，服务器不会接受请求。
412 Precondition Failed	请求中的前提条件被服务器评估为失败。
413 Request Entity Too Large	由于所请求的实体的太大，服务器不会接受请求。
414 Request-url Too Long	由于url太长，服务器不会接受请求。当post请求被转换为带有很长的查询信息的get请求时，就会发生这种情况。
415 Unsupported Media Type	由于媒介类型不被支持，服务器不会接受请求。
416 Requested Range Not Satisfiable	服务器不能满足客户在请求中指定的Range头。
417 Expectation Failed	执行失败。
423	锁定的错误。

5xx:服务器错误

消息	描述
500 Internal Server Error	请求未完成。服务器遇到不可预知的情况。
500.12	应用程序正忙于在 Web 服务器上重新启动。
500.13	Web 服务器太忙。
500.15	不允许直接请求 Global.asa。
500.16	UNC 授权凭据不正确。这个错误代码为 IIS 6.0 所专用。
500.18	URL 授权存储不能打开。这个错误代码为 IIS 6.0 所专用。
500.100	内部 ASP 错误。
501 Not Implemented	请求未完成。服务器不支持所请求的功能。
502 Bad Gateway	请求未完成。服务器从上游服务器收到一个无效的响应。
502.1	CGI 应用程序超时。　·
502.2	CGI 应用程序出错。
503 Service Unavailable	请求未完成。服务器临时过载或当机。
504 Gateway Timeout	网关超时。
505 HTTP Version Not Supported	服务器不支持请求中指明的HTTP协议版本。

版本历史

超文本传输协议已演化出了很多版本，它们中的大部分都是向下兼容的。在 RFC 2145 中描述了 HTTP 版本号的用法。客户端在请求开始时，会告诉服务器它采用的协议版本号，而后者则在响应中会采用相同或更早协议版本。

#	版本	说明	主要功能	备注
01	HTTP 0.9	只接受 GET 一种请求方法，没有在通讯中指定版本号，且不支持请求头。	由于该版本不支持 POST 方法，所以客户端无法向服务器传递太多信息。	已过时
02	HTTP 1.0	这是第一个在通讯中指定版本号的 HTTP 协议版本。	至今仍被广泛采用，特别是在代理服务器中。
03	HTTP 1.1	当前版本。持久连接被默认采用，能很好地配合代理服务器工作。支持以管道方式同时发送多个请求，以降低线路负载，提高传输速度。	HTTP 1.1 相较  HTTP 1.0 协议的区别主要体现在： 01、缓存处理 02、带宽优化及网络连接的使用 03、错误通知的管理 04、消息在网络中的发送 05、互联网地址的维护 06、安全性及完整性

版权声明：
本文为独家原创稿件，版权归 德云社区，未经许可不得转载；否则，将追究其法律责任。