超文本传输协定(HTTP,HyperText Transfer Protocol)是网际网路上套用最为广泛的一种网路协定。所有的WWW档案都必须遵守这个标準。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。1960年美国人Ted Nelson构思了一种通过计算机处理文本信息的方法,并称之为超文本(hypertext),这成为了HTTP超文本传输协定标準架构的发展根基。Ted Nelson组织协调全球资讯网协会(World Wide Web Consortium)和网际网路工程工作小组(Internet Engineering Task Force )共同合作研究,最终发布了一系列的RFC,其中着名的RFC 2616定义了HTTP 1.1。
技术架构
HTTP是一个客户端和伺服器端请求和应答的标準(TCP)。客户端是终端用户,伺服器端是网站。通过使用Web浏览器、网路爬虫或者其它的工具,客户端发起一个到伺服器上指定连线埠(默认连线埠为80)的HTTP请求。(我们称这个客户端)叫用户代理(user agent)。应答的伺服器上存储着(一些)资源,比如HTML档案和图像。(我们称)这个应答伺服器为源伺服器(origin server)。在用户代理和源伺服器中间可能存在多箇中间层,比如代理,网关,或者隧道(tunnels)。儘管TCP/IP协定是网际网路上最流行的套用,HTTP协定并没有规定必须使用它和(基于)它支持的层。 事实上,HTTP可以在任何其他网际网路协定上,或者在其他网路上实现。HTTP只假定(其下层协定提供)可靠的传输,任何能够提供这种保证的协定都可以被其使用。
通常,由HTTP客户端发起一个请求,建立一个到伺服器指定连线埠(默认是80连线埠)的TCP连线。HTTP伺服器则在那个连线埠监听客户端传送过来的请求。一旦收到请求,伺服器(向客户端)发回一个状态行,比如"HTTP/1.1 200 OK",和(回响的)讯息,讯息的讯息体可能是请求的档案、错误讯息、或者其它一些信息。HTTP使用TCP而不是UDP的原因在于(打开)一个网页必须传送很多数据,而TCP协定提供传输控制,按顺序组织数据,和错误纠正。
通过HTTP或者HTTPS协定请求的资源由统一资源标示符(Uniform Resource Identifiers)(或者,更準确一些,URLs)来标识。
协定功能
HTTP协定(HyperText Transfer Protocol,超文本传输协定)是用于从WWW伺服器传输超文本到本地浏览器的传输协定。它可以使浏览器更加高效,使网路传输减少。它不仅保证计算机正确快速地传输超文本文档,还确定传输文档中的哪一部分,以及哪部分内容显示(如文本先于图形)等。
HTTP是客户端浏览器或其他程式与Web服务器之间的套用层通信协定。在Internet上的Web伺服器上存放的都是超文本信息,客户机需要通过HTTP协定传输所要访问的超文本信息。HTTP包含命令和传输信息,不仅可用于Web访问,也可以用于其他网际网路/内联网套用系统之间的通信,从而实现各类套用资源超媒体访问的集成。
我们在浏览器的地址栏里输入的网站地址叫做URL (Uniform Resource Locator,统一资源定位符)。就像每家每户都有一个门牌地址一样,每个网页也都有一个Internet地址。当你在浏览器的地址框中输入一个URL或是单击一个超级连结时,URL就确定了要浏览的地址。浏览器通过超文本传输协定(HTTP),将Web伺服器上站点的网页代码提取出来,并翻译成漂亮的网页。
协定基础
HTTP(HyperText Transport Protocol)是超文本传输协定的缩写,它用于传送WWW方式的数据,关于HTTP协定的详细内容请参考RFC2616。HTTP协定採用了请求/回响模型。客户端向伺服器传送一个请求,请求头包含请求的方法、URL、协定版本、以及包含请求修饰符、客户信息和内容的类似于MIME的讯息结构。伺服器以一个状态行作为回响,回响的内容包括讯息协定的版本,成功或者错误编码加上包含伺服器信息、实体元信息以及可能的实体内容。
通常HTTP讯息包括客户机向伺服器的请求讯息和伺服器向客户机的回响讯息。这两种类型的讯息由一个起始行,一个或者多个头域,一个指示头域结束的空行和可选的讯息体组成。HTTP的头域包括通用头,请求头,回响头和实体头四个部分。每个头域由一个域名,冒号(:)和域值三部分组成。域名是大小写无关的,域值前可以添加任何数量的空格符,头域可以被扩展为多行,在每行开始处,使用至少一个空格或制表符。
通用头域
通用头域包含请求和回响讯息都支持的头域,通用头域包含Cache-Control、Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via。对通用头域的扩展要求通讯双方都支持此扩展,如果存在不支持的通用头域,一般将会作为实体头域处理。下面简单介绍几个在UPnP讯息中使用的通用头域
1.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代表这个间隔值得大小。
2.Date头域
Date头域表示讯息传送的时间,时间的描述格式由rfc822定义。例如,Date:Mon,31Dec200104:25:57GMT。Date描述的时间表示世界标準时,换算成本地时间,需要知道用户所在的时区。
3.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。对请求头域的扩展要求通讯双方都支持,如果存在不支持的请求头域,一般将会作为实体头域处理。
典型的请求讯息
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下的档案。棕色的部分表示请求头域的信息,绿色的部分表示通用头部分。
1.Host头域
Host头域指定请求资源的Intenet主机和连线埠号,必须表示请求url的原始伺服器或网关的位置。HTTP/1.1请求必须包含主机头域,否则系统会以400状态码返回。
2.Referer头域
Referer头域允许客户端指定请求uri的源资源地址,这可以允许伺服器生成回退鍊表,可用来登入、最佳化cache等。他也允许废除的或错误的连线由于维护的目的被追蹤。如果请求的uri没有自己的uri地址,Referer不能被传送。如果指定的是部分uri地址,则此地址应该是一个相对地址。
3.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)。
4.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:bytes55/40279980
上例第一行表示HTTP服务端回响一个GET方法。棕色的部分表示回响头域的信息,绿色的部分表示通用头部分,红色的部分表示实体头域的信息。
1.Location回响头
Location回响头用于重定向接收者到一个新URI地址。
2.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定义。
1.Content-Type实体头
Content-Type实体头用于向接收方指示实体的介质类型,指定HEAD方法送到接收方的实体介质类型,或GET方法传送的请求介质类型
2.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表示实际传送的位元组数。
3.Last-modified实体头
Last-modified实体头指定伺服器上保存内容的修订时间。
例如,传送头500个位元组次栏位的形式Content-Range:bytes0-499/1234如果一个http讯息包含此节(例如,对範围请求的回响或对一系列範围的重叠请求),Content-Range表示传送的範围,Content-Length表示实际传送的位元组数。
运作方式
在WWW中,“客户”与“伺服器”是一个相对的概念,只存在于一个特定的连线期间,即在某个连线中的客户在另一个连线中可能作为伺服器。基于HTTP协定的客户/伺服器模式的信息交换过程,它分四个过程建立连线、传送请求信息、传送回响信息、关闭连线。
HTTP协定是基于请求/回响範式的。一个客户机与伺服器建立连线后,传送一个请求给伺服器,请求方式的格式为,统一资源标识符、协定版本号,后边是MIME信息包括请求修饰符、客户机信息和可能的内容。伺服器接到请求后,给予相应的回响信息,其格式为一个状态行包括信息的协定版本号、一个成功或错误的代码,后边是MIME信息包括伺服器信息、实体信息和可能的内容。其实简单说就是任何伺服器除了包括HTML档案以外,还有一个HTTP驻留程式,用于回响用户请求。你的浏览器是HTTP客户,向伺服器传送请求,当浏览器中输入了一个开始档案或点击了一个超级连结时,浏览器就向伺服器传送了HTTP请求,此请求被送往由IP位址指定的URL。驻留程式接收到请求,在进行必要的操作后回送所要求的档案。在这一过程中,在网路上传送和接收的数据已经被分成一个或多个数据包(packet),每个数据包包括要传送的数据;控制信息,即告诉网路怎样处理数据包。TCP/IP决定了每个数据包的格式。如果事先不告诉你,你可能不会知道信息被分成用于传输和再重新组合起来的许多小块。
许多HTTP通讯是由一个用户代理初始化的并且包括一个申请在源伺服器上资源的请求。最简单的情况可能是在用户代理(UA)和源伺服器(O)之间通过一个单独的连线来完成。
当一个或多箇中介出现在请求/回响链中时,情况就变得複杂一些。中介有三种代理(Proxy)、网关(Gateway)和通道(Tunnel)。一个代理根据URI的绝对格式来接受请求,重写全部或部分讯息,通过URI的标识把已格式化过的请求传送到伺服器。网关是一个接收代理,作为一些其它伺服器的上层,并且如果必须的话,可以把请求翻译给下层的伺服器协定。一个通道作为不改变讯息的两个连线之间的中继点。当通讯需要通过一个中介(例如防火墙等)或者是中介不能识别讯息的内容时,通道经常被使用。
报文格式
HTTP报文由从客户机到伺服器的请求和从伺服器到客户机的回响构成。请求报文格式如下
请求行 - 通用信息头 - 请求头 - 实体头 - 报文主体
请求行以方法栏位开始,后面分别是 URL 栏位和 HTTP 协定版本栏位,并以 CRLF 结尾。SP 是分隔设定。除了在的 CRLF 序列中 CF 和 LF 是必需的之外,其他都可以不要。有关通用信息头,请求头和实体头方面的具体内容可以参照相关档案。
应答报文格式如下
状态行 - 通用信息头 - 回响头 - 实体头 - 报文主体
状态码元由3位数字组成,表示请求是否被理解或被满足。原因分析是对原文的状态码作简短的描述,状态码用来支持自动操作,而原因分析用来供用户使用。客户机无需用来检查或显示语法。有关通用信息头,回响头和实体头方面的具体内容可以参照相关档案。
工作原理
一次HTTP操作称为一个事务,其工作过程可分为四步
客户机与伺服器需要建立连线。只要单击某个超级连结,HTTP的工作就开始了。
建立连线后,客户机传送一个请求给伺服器,请求方式的格式为统一资源标识符(URL)、协定版本号,后边是MIME信息包括请求修饰符、客户机信息和可能的内容。
伺服器接到请求后,给予相应的回响信息,其格式为一个状态行,包括信息的协定版本号、一个成功或错误的代码,后边是MIME信息包括伺服器信息、实体信息和可能的内容。
客户端接收伺服器所返回的信息通过浏览器显示在用户的显示屏上,然后客户机与伺服器下线。
如果在以上过程中的某一步出现错误,那幺产生错误的信息将返回到客户端,由显示屏输出。对于用户来说,这些过程是由HTTP自己完成的,用户只要用滑鼠点击,等待信息显示就可以了。
许多HTTP通讯是由一个用户代理初始化的并且包括一个申请在源伺服器上资源的请求。最简单的情况可能是在用户代理和伺服器之间通过一个单独的连线来完成。在Internet上,HTTP通讯通常发生在TCP/IP连线之上。预设连线埠是TCP 80,但其它的连线埠也是可用的。但这并不预示着HTTP协定在Internet或其它网路的其它协定之上才能完成。HTTP只预示着一个可靠的传输。
这个过程就好像我们打电话订货一样,我们可以打电话给商家,告诉他我们需要什幺规格的商品,然后商家再告诉我们什幺商品有货,什幺商品缺货。这些,我们是通过电话线用电话联繫(HTTP是通过TCP/IP),我们也可以通过传真,只要商家那边也有传真。
状态讯息
讯息 | 描述 |
---|---|
100 Continue | 伺服器仅接收到部分请求,一旦伺服器并没有拒绝该请求,客户端应该继续传送其余的请求。 |
101 Switching Protocols | 伺服器转换协定伺服器将遵从客户的请求转换到一种协定。 |
讯息 | 描述 |
---|---|
200 OK | 请求成功(其后是对GET和POST请求的应答文档。) |
201 Created | 请求被创建完成,新的资源被创建。 |
202 Accepted | 供处理的请求已被接受,处理未完成。 |
203 Non-authoritative Information | 文档已经正常地返回,但一些应答头可能不正确,因为使用的是文档的拷贝。 |
204 No Content | 没有新文档。浏览器应该继续显示原来的文档。如果用户定期地刷新页面,而Servlet可以确定用户文档足够新,这个状态代码是很有用的。 |
205 Reset Content | 没有新文档。但浏览器应该重置它所显示的内容。用来强制浏览器清除表单输入内容。 |
206 Partial Content | 客户传送了一个带有Range头的GET请求,伺服器完成了它。 |
讯息 | 描述 |
---|---|
300 Multiple Choices | 多重选择。连结列表。用户可以选择某连结到达目的地。最多允许五个地址。 |
301 Moved Permanently | 所请求的页面已经转移至新的url。 |
302 Found | 所请求的页面已经临时转移至新的url。 |
303 See Other | 所请求的页面可在别的url下被找到。 |
304 Not Modified | 未按预期修改文档。客户端有缓冲的文档并发出了一个条件性的请求(一般是提供If-Modified-Since头表示客户只想比指定日期更新的文档)。伺服器告诉客户,原来缓冲的文档还可以继续使用。 |
305 Use Proxy | 客户请求的文档应该通过Location头所指明的代理伺服器提取。 |
306 Unused | 此代码被用于前一版本。目前已不再使用,代码依然被保留。 |
307 Temporary Redirect | 被请求的页面已经临时移至新的url。 |
讯息 | 描述 |
---|---|
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 | 锁定的错误。 |
讯息 | 描述 |
---|---|
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版本号的用法。客户端在请求的开始告诉伺服器它採用的协定版本号,而后者则在回响中採用相同或者更早的协定版本。
0.9 已过时。只接受 GET 一种请求方法,没有在通讯中指定版本号,且不支持请求头。由于该版本不支持 POST 方法,所以客户端无法向伺服器传递太多信息。
HTTP/1.0 这是第一个在通讯中指定版本号的HTTP 协定版本,至今仍被广泛採用,特别是在代理伺服器中。
HTTP/1.1 当前版本。持久连线被默认採用,并能很好地配合代理伺服器工作。还支持以管道方式传送多个请求,以便降低线路负载,提高传输速度。
HTTP/1.1相较于 HTTP/1.0 协定的区别主要体现在
1 快取处理
2 频宽最佳化及网路连线的使用
3 错误通知的管理
4 讯息在网路中的传送
5 网际网路地址的维护
6 安全性及完整性