HTTP状态码完整介绍

 

HTTP状态码是什么?HTTP状态码有什么用处?如何处理HTTP状态码可以和搜索引擎更友好?技巧在哪里?更有利于网站优化?HTTP状态码如何监测?这些都是许多刚入门seo优化这个行业的新手常常问的问题，下面

HTTP状态码是什么?HTTP状态码有什么用处?如何处理HTTP状态码可以和搜索引擎更友好?技巧在哪里?更有利于网站优化?HTTP状态码如何监测?这些都是许多刚入门seo优化这个行业的新手常常问的问题，下面咱们一一作出解答。 　　 Seo技巧_HTTP状态码是什么? 　　HTTP协议是典型请求/响应模式，客户端请求服务器，客户端和服务器创建链接。 　　客户端发送一段数据给服务器例以下面的一段请求： 　　Host: download.microtool.de 　　Accept: */* 　　Pragma: no-cache 　　Cache-Control: no-cache 　　User-Agent: Mozilla/4.04[en](Win95;I;Nav) 　　Range: bytes=554554- 　　服务器在接受到这个请求后向客户端发出响应数据以下： 　　HTTP/1.0 200 OK 　　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/1.0 200 OK”说明客户端请求成功，返回服务器成功状态码，注意如今HTTP状态码出现了，若是服务器发现，客户端所请求的页面不存在，那么应该返回的是这段数据“HTTP/1.0404OK”下面咱们列出经常使用的HTTP状态码对照表： 　　 用来帮助各位seo对照本身的状态码。 　　Seo技巧_HTTP状态码有什么用处? 　　HTTP状态码的做用是帮助客户端(浏览器，搜索引擎)了解请求/响应服务器的状态。 　　 Seo技巧_如何处理HTTP状态码可以和搜索引擎更友好? 　　在网站设计中，出现错误页面是常常会发生的，当搜索引擎爬虫来访问一个网站本不存在的一个页面时或者网站URL生成规则更改时，都会返回404错误页面，这样搜索引擎都会自动删除搜索引擎关于这个URL的信息，问题出现了：若是是某个访问者来到了这个404页面，咱们怎么办?咱们要白白放走本身的访客(有可能成为本身的客户)，不行，不能放走这个潜在的客户，咱们seo也想到了解决的办法，本身制做404页面，不只提示没有找到改网页，咱们还在本身制做的404页面上作一个栏目导航，供访客再一次的点击，可是404页面的制做，不是几句话能说明白的，咱们将在下一节专门介绍404页面的制做，而且保证服务器返回的状态码也是404，而不是别的状态码。 　　301状态码对搜索引擎算是比较友好的，若是出现要转移权重，建议用301永久定位。 　　好比：你有两个域名www.xxxx.com 和xxxx.com(搜索引擎看来这是2个域名) ，为了可以不丢失在浏览器中输入seo10e的访客，也为了可以把权重转移到www.xxxx.com 咱们就应该设置服务器，把xxxx.com永久定位到www.xxxx.com 。 　　总之一句话，http状态码技巧若是处理好，对网站优化有益无害，若是处理很差，可能会下降您的网站的权重，更有可能让搜索殷勤爬虫感到您的网站不太友好。 　　Seo技巧_HTTP状态码如何监测? 　　http状态码的监测，有2种方法： 　　1. 查看网站日志 　　221.201.77.63 - - [02/Jul/2006:15:30:41 +0800] “GET /seoblog/2006/04/17/user-friendly-website/HTTP/1.1″ 200 19031 “http://www.baidu.com/s? wd=%C2%EA%D1%C5%B2%BF%C2%E4&cl=3&tn=baiduerr″ “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;SV1; Alexa Toolbar)” 　　221.201.77.63 这个IP地址在 某一时刻，用get请求方式，请求过GET /seoblog/2006/04/17/user-friendly-website/HTTP/1.1 的内容，而且服务器返回了“200”状态码。 　　2. 经过一些网站HTTP分析软件 httpwatch 能够看见在访问网站时整个页面的请求和响应，也能看见状态码。若是发现那个页面出现状态码问题能够及时解决调影响seo优化对搜索引擎不友好的因素。 　　总结：HTTP状态码seo技巧应该注意404状态码和301状态码，若是处理很差会影响到网站和搜索引擎的友好度 服务器http请求的成功与否会返回一系列数据代码，称为状态码，用户客户端和搜索引擎都会识别这写状态码从而做出正确的反映！  Successful ================================= 200 OK 指示客服端的请求已经成功收到，解析，接受。 201 Created 请求已经完成并一个新的返回资源被建立。被建立的资源多是一个URI资源，一般URI资源在Location头指定。回送应该包含一个实体数据 而且包含资源特性以及location经过用户或者用户代理来选择合适的方法。实体数据格式经过煤体类型来指定即content-type头。最开始服务器 必须建立指定的资源在返回201状态码以前。若是行为没有被马上执行，服务器应该返回202。 202 Accepted 请求已经被接受用来处理。可是处理并无完成。请求可能或者根本没有遵守执行，由于处理实际执行过程当中可能被拒绝。 203 Non-Authoritative Information 204 No Content 服务器已经接受请求而且不必返回实体数据，可能须要返回更新信息。回送可能包含新的或更新信息由entity-headers呈现。 205 Reset Content 服务器已经接受请求而且用户代理应该从新设置文档视图。 206 Partial Content 服务器已经接受请求GET请求资源的部分。请求必须包含一个Range头信息以指示获取范围可能必须包含If-Range头信息以成立请求条件。 Redirection ================================== 300 Multiple Choices 请求资源符合任何一个呈现方式。 301 Moved Permanently 请求的资源已经被赋予一个新的URI。 302 Found 经过不一样的URI请求资源的临时文件。 303 See Other 304 Not Modified 若是客服端已经完成一个有条件的请求而且请求是容许的，可是这个文档并无改变，服务器应该返回304状态码。304 状态码必定不能包含信息主体，从而一般经过一个头字段后的第一个空行结束。 305 Use Proxy 海姹网（网址:http://www.seacha.com），标签：HTTP状态码完整介绍， HTTP,协议,状态码,seo 请求的资源必须经过代理（由Location字段指定）来访问。Location资源给出了代理的URI。 306 Unused 307 Temporary Redirect Client Error ===================== 400 Bad Request 由于错误的语法致使服务器没法理解请求信息。 401 Unauthorized 若是请求须要用户验证。回送应该包含一个WWW-Authenticate头字段用来指明请求资源的权限。 402 Payment Required 保留状态码 403 Forbidden 服务器接受请求，可是被拒绝处理。 404 Not Found 服务器已经找到任何匹配Request-URI的资源。 405 Menthod Not Allowed Request-Line请求的方法不被容许经过指定的URI。 406 Not Acceptable 407 Proxy Authentication Required 408 Reqeust Timeout 客服端没有提交任何请求在服务器等待处理时间内。 409 Conflict 410 Gone 411 Length Required 服务器拒绝接受请求在没有定义Content-Length字段的状况下。 412 Precondition Failed 413 Request Entity Too Large 服务器拒绝处理请求由于请求数据超过服务器可以处理的范围。服务器可能关闭当前链接来阻止客服端继续请求。 414 Request-URI Too Long 服务器拒绝服务当前请求由于URI的长度超过了服务器的解析范围。 415 Unsupported Media Type 服务器拒绝服务当前请求由于请求数据格式并不被请求的资源支持。 416 Request Range Not Satisfialbe 417 Expectation Failed Server Error =================================== 500 Internal Server Error 服务器遭遇异常阻止了当前请求的执行 501 Not Implemented 服务器没有相应的执行动做来完成当前请求。 502 Bad Gateway 503 Service Unavailable 由于临时文件超载致使服务器不能处理当前请求。 504 Gateway Timeout 505 Http Version Not Supported （一）初识HTTP消息头 但凡搞WEB开发的人都离不开HTTP（超文本传输协议），而要了解HTTP，除了HTML自己之外，还有一部分不可忽视的就是HTTP消息头。 作 过Socket编程的人都知道，当咱们设计一个通讯协议时，“消息头/消息体”的分割方式是很经常使用的，消息头告诉对方这个消息是干什么的，消息体告诉对方 怎么干。HTTP传输的消息也是这样规定的，每个HTTP包都分为HTTP头和HTTP体两部分，后者是可选的，而前者是必须的。每当咱们打开一个网 页，在上面点击右键，选择“查看源文件”，这时看到的HTML代码就是HTTP的消息体，那么消息头又在哪呢？IE浏览器不让咱们看到这部分，但咱们能够 经过截取数据包等方法看到它。 下面就来看一个简单的例子： 首先制做一个很是简单的网页，它的内容只有一行： <html><body>hello world</body></html> 把它放到WEB服务器上，好比IIS，而后用IE浏览器请求这个页面（http://localhost:8080/simple.htm），当咱们请求这个页面时，浏览器实际作了如下四项工做： 1 解析咱们输入的地址，从中分解出协议名、主机名、端口、对象路径等部分，对于咱们的这个地址，解析获得的结果以下： 协议名：http 主机名：localhost 端口：8080 对象路径：/simple.htm 2 把以上部分结合本机本身的信息，封装成一个HTTP请求数据包 3 使用TCP协议链接到主机的指定端口（localhost, 8080），并发送已封装好的数据包 4 等待服务器返回数据，并解析返回数据，最后显示出来 由截取到的数据包咱们不难发现浏览器生成的HTTP数据包的内容以下： GET /simple.htm HTTP/1.1<CR> Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*<CR> Accept-Language: zh-cn<CR> Accept-Encoding: gzip, deflate<CR> User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)<CR> Host: localhost:8080<CR> Connection: Keep-Alive<CR> <CR> 为了显示清楚我把全部的回车的地方都加上了“<CR>”，注意最后还有一个空行加一个回车，这个空行正是HTTP规定的消息头和消息体的分界线，第一个空行如下的内容就是消息体，这个请求数据包是没有消息体的。 消 息的第一行“GET”表示咱们所使用的HTTP动做，其余可能的还有“POST”等，GET的消息没有消息体，而POST消息是有消息体的，消息体的内容 就是要POST的数据。后面/simple.htm就是咱们要请求的对象，以后HTTP1.1表示使用的是HTTP1.1协议。 第二行表示咱们所用的浏览器能接受的Content-type，三四两行则是语言和编码信息，第五行显示出本机的相关系信息，包括浏览器类型、操做系统信息等，不少网站能够显示出你所使用的浏览器和操做系统版本，就是由于能够从这里获取到这些信息。 第六行表示咱们所请求的主机和端口，第七行表示使用Keep-Alive方式，即数据传递完并不当即关闭链接。 服务器接收到这样的数据包之后会根据其内容作相应的处理，例如查找有没有“/simple.htm”这个对象，若是有，根据服务器的设置来决定如何处理，若是是HTM，则不须要什么复杂的处理，直接返回其内容便可。但在直接返回以前，还须要加上HTTP消息头。 服务器发回的完整HTTP消息以下： HTTP/1.1 200 OK<CR> Server: Microsoft-IIS/5.1<CR> X-Powered-By: ASP.NET<CR> Date: Fri, 03 Mar 2006 06:34:03 GMT<CR> Content-Type: text/html<CR> Accept-Ranges: bytes<CR> Last-Modified: Fri, 03 Mar 2006 06:33:18 GMT<CR> ETag: "5ca4f75b8c3ec61:9ee"<CR> Content-Length: 37<CR> <CR> <html><body>hello world</body></html> 海姹网（网址:http://www.seacha.com），标签：HTTP状态码完整介绍， HTTP,协议,状态码,seo 一样，我用“<CR>”来表示回车。能够看到，这个消息也是用空行切分红消息头和消息体两部分，消息体的部分正是咱们前面写好的HTML代码。 消息头第一行“HTTP/1.1”也是表示所使用的协议，后面的“200 OK”是HTTP返回代码，200就表示操做成功，还有其余常见的如404表示对象未找到，500表示服务器错误，403表示不能浏览目录等等。 第 二行表示这个服务器使用的WEB服务器软件，这里是IIS 5.1。第三行是ASP.Net的一个附加提示，没什么实际用处。第四行是处理此请求的时间。第五行就是所返回的消息的content-type，浏览器 会根据它来决定如何处理消息体里面的内容，例如这里是text/html，那么浏览器就会启用HTML解析器来处理它，若是是image/jpeg，那么 就会使用JPEG的解码器来处理。 消息头最后一行“Content-Length”表示消息体的长度，从空行之后的内容算起，以字节为单位，浏览器接收到它所指定的字节数的内容之后就会认为这个消息已经被完整接收了。 理解HTTP消息头 （二） 常见的HTTP返回码 上一篇文章里我简要的说了说HTTP消息头的格式，注意到在服务器返回的HTTP消息头里有一个“HTTP/1.1 200 OK”，这里的200是HTTP规定的返回代码，表示请求已经被正常处理完成。浏览器经过这个返回代码就能够知道服务器对所发请求的处理状况是什么，每一 种返回代码都有本身的含义。这里列举几种常见的返回码。 1 403 Access Forbidden 若是咱们试图请求服务器上一个文件夹，而在WEB服务器上这个文件夹并无容许对这个文件夹列目录的话，就会返回这个代码。一个完整的403回复多是这样的：（IIS5.1） HTTP/1.1 403 Access Forbidden Server: Microsoft-IIS/5.1 Date: Mon, 06 Mar 2006 08:57:39 GMT Connection: close Content-Type: text/html Content-Length: 172 <html><head><title>Directory Listing Denied</title></head> <body><h1>Directory Listing Denied</h1>This Virtual Directory does not allow contents to be listed.</body></html> 2 404 Object not found 当咱们请求的对象在服务器上并不存在时，就会给出这个返回代码，这可能也是最多见的错误代码了。IIS给出的404消息内容很长，除了消息头之外还有一个完整的说明“为何会这样”的网页。APACHE服务器的404消息比较简短，以下： HTTP/1.1 404 Not Found Date: Mon, 06 Mar 2006 09:03:14 GMT Server: Apache/2.0.55 (Unix) PHP/5.0.5 Content-Length: 291 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>404 Not Found</title> </head><body> <h1>Not Found</h1> <p>The requested URL /notexist was not found on this server.</p> <hr> <address>Apache/2.0.55 (Unix) PHP/5.0.5 Server at localhost Port 8080</address> </body></html> 也许你会问，不管是404仍是200，都会在消息体内给出一个说明网页，那么对于客户端来讲两者有什么区别呢？一个比较明显的区别在于200是 成功请求，浏览器会记录下这个地址，以便下次再访问时能够自动提示该地址，而404是失败请求，浏览器只会显示出返回的页面内容，并不会记录此地址，要再 次访问时还须要输入完整的地址。 3 401 Access Denied 当WEB服务器不容许匿名访问，而咱们又没有提供正确的用户名/密码时，服务器就会给出这个返回代码。在IIS中，设置IIS的安全属性为不容许匿名访问（以下图），此时直接访问的话就会获得如下返回结果： HTTP/1.1 401 Access Denied Server: Microsoft-IIS/5.1 Date: Mon, 06 Mar 2006 09:15:55 GMT WWW-Authenticate: Negotiate WWW-Authenticate: NTLM Connection: close Content-Length: 3964 Content-Type: text/html <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <html dir=ltr> …… 此时浏览器上给出的提示以下图，让咱们输入用户名和密码： 因返回信息中消息体较长，只取前面两行内容。注意，若是是用localhost来访问本机的IIS，因IE能够直接取得当前用户的身份，它会和服务器间直接进行协商，因此不会看到401提示。 当咱们在输入了用户名和密码之后，服务器与客户端会再进行两次对话。首先客户端向服务器索取一个公钥，服务器端会返回一个公钥，两者都用BASE64编码，相应的消息以下（编码部分已经作了处理）： GET / HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */* Accept-Language: zh-cn Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727) Host: 192.168.0.55:8080 Connection: Keep-Alive Authorization: Negotiate ABCDEFG…… HTTP/1.1 401 Access Denied Server: Microsoft-IIS/5.1 Date: Mon, 06 Mar 2006 09:20:53 GMT WWW-Authenticate: Negotiate HIJKLMN…… Content-Length: 3715 Content-Type: text/html <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <html dir=ltr> …… 客户端拿到公钥以后使用公钥对用户名和密码进行加密码，而后把加密之后的结果从新发给服务器： GET / HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */* Accept-Language: zh-cn 海姹网（网址:http://www.seacha.com），标签：HTTP状态码完整介绍， HTTP,协议,状态码,seo Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727) Host: 192.168.0.55:8080 Connection: Keep-Alive Authorization: Negotiate OPQRST…… 这样，若是验证经过，服务器端就会把请求的内容发送过来了，也就是说禁止匿名访问的网站会通过三次请求才能够看到页面。但由于客户端浏览器已经缓存了公钥，用同一个浏览器窗口再次请求这个网站上的其它页面时就能够直接发送验证信息，从而一次交互就能够完成了。 4 302 Object Moved 用过ASP的人都知道ASP中页面重定向至少有Redirect和Transfer两种方法。二的区别在于Redirect是客户端重定向，而Transfer是服务器端重定向，那么它们具体是如何经过HTTP消息头实现的呢？ 先来看一下Transfer的例子： 例如ASP文件1.asp只有一行 <% Server.Transfer "1.htm" %> HTML文件1.htm也只有一行： <p>this is 1.htm</p> 若是咱们从浏览器里请求1.asp，发送的请求是： GET /1.asp HTTP/1.1 Accept: */* Accept-Language: zh-cn Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727) Host: localhost:8080 Connection: Keep-Alive Cookie: ASPSESSIONIDACCTRTTT=PKKDJOPBAKMAMBNANIPIFDAP 注意请求的文件确实是1.asp，而获得的回应则是： HTTP/1.1 200 OK Server: Microsoft-IIS/5.1 Date: Mon, 06 Mar 2006 12:52:44 GMT X-Powered-By: ASP.NET Content-Length: 20 Content-Type: text/html Cache-control: private <p>this is 1.htm</p> 不难看出，经过Server.Transfer语句服务器端已经作了页面重定向，而客户端对此一无所知，表面上看上去获得的就是1.asp的结果。 若是把1.asp的内容改成： <% Response.Redirect "1.htm" %> 再次请求1.asp，发送的请求没有变化，获得的回应却变成了： HTTP/1.1 302 Object moved Server: Microsoft-IIS/5.1 Date: Mon, 06 Mar 2006 12:55:57 GMT X-Powered-By: ASP.NET Location: 1.htm Content-Length: 121 Content-Type: text/html Cache-control: private <head><title>Object moved</title></head> <body><h1>Object Moved</h1>This object may be found <a HREF="">here</a>.</body> 注意HTTP的返回代码由200变成了302，表示这是一个重定向消息，客户端须要根据消息头中Location字段的值从新发送请求，因而就有了下面一组对话： GET /1.htm HTTP/1.1 Accept: */* Accept-Language: zh-cn Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727) Host: localhost:8080 Connection: Keep-Alive If-Modified-Since: Thu, 02 Mar 2006 06:50:13 GMT If-None-Match: "b224758ec53dc61:9f0" Cookie: ASPSESSIONIDACCTRTTT=PKKDJOPBAKMAMBNANIPIFDAP HTTP/1.1 200 OK Server: Microsoft-IIS/5.1 X-Powered-By: ASP.NET Date: Mon, 06 Mar 2006 12:55:57 GMT Content-Type: text/html Accept-Ranges: bytes Last-Modified: Mon, 06 Mar 2006 12:52:32 GMT ETag: "76d85bd51c41c61:9f0" Content-Length: 20 <p>this is 1.htm</p> 很明显，两种重定向方式虽然看上去结果很像，但在实现原理上有很大的不一样。 5 500 Internal Server Error 500号错误发生在服务器程序有错误的时候，例如，ASP程序为 <% if %> 显然这个程序并不完整，因而获得的结果为： HTTP/1.1 500 Internal Server Error Server: Microsoft-IIS/5.1 Date: Mon, 06 Mar 2006 12:58:55 GMT X-Powered-By: ASP.NET Content-Length: 4301 Content-Type: text/html Expires: Mon, 06 Mar 2006 12:58:55 GMT Set-Cookie: ASPSESSIONIDACCTRTTT=ALKDJOPBPPKNPCNOEPCNOOPD; path=/ Cache-control: private <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <html dir=ltr> …… 服务器发送了500号错误，而且后面经过HTML的方式说明了错误的缘由。 理解HTTP消息头 （三） （三） 客户端发送的内容 这一次主要来观察HTTP消息头中客户端的请求，从中找到一些有意思的内容。 1 HTTP_REFERER 写两个简单的网页： a.htm： <a href=b.htm>to page b</a> b.htm： haha 内容很简单，就是网页A中有一个到B的连接。把它们放到IIS上，并访问网页A，从中再点击到B的连接，因而看到了B页的“haha”。那么这两次请求有什么不一样吗？观察它们所发送的HTTP消息头，最明显的区别就是访问B页时比访问A页时多了一行： Referer: http://localhost/a.htm 这一行就表示，用户要访问的B页是从A页连接过来的。 服务器端要想取得这个值也是很容易的，以ASP为例，只须要写一句 <% =Request.ServerVariables("HTTP_REFERER") %> 就能够了。 一 些网站经过HTTP_REFERER来作安全验证，判断用户是否是从容许的页面连接来的，而不是直接从浏览器上打URL或从其余页面连接过来，这样能够从 必定程度上防止网页被作非法使用。但从上述原理来看，想要骗过服务器也并不困难，只要手工构造输入的HTTP消息头就能够了，其余经常使用的手段还有经过 HOSTS文件伪造域名等。 除了超连接之外，还有其余几种方式会致使HTTP_REFERER信息被发送，如： 内联框架：<iframe src=b.asp></iframe> 框架集：<frameset><frame src=b.asp></frameset> 表单提交：<form action=b.asp><input type=submit></form> SCRIPT引用：<script src=b.asp></script> 海姹网（网址:http://www.seacha.com），标签：HTTP状态码完整介绍， HTTP,协议,状态码,seo CSS引用：<link rel=stylesheet type=text/css href=b.asp> XML数据岛：<xml src=b.asp></xml> 而如下形式不会发送HTTP_REFERER： script转向：<script>location.href="b.asp"</script> script开新窗口：<script>window.open("b.asp");</script> META转向：<meta http-equiv="refresh" content="0;URL=b.asp"> 引入图片：<img src=b.asp> 2 COOKIE COOKIE是你们都很是熟悉的了，经过它能够在客户端保存用户状态，即便用户关闭浏览器也能继续保存。那么客户端与服务器端是如何交换COOKIE信息的呢？没错，也是经过HTTP消息头。 首先写一个简单的ASP网页： <% Dim i i =  Request.Cookies("key") Response.Write i Response.Cookies("key") = "haha" Response.Cookies("key").Expires = #2007-1-1# %> 第 一次访问此网页时，屏幕上一片白，第二次访问时，则会显示出“haha”。经过阅读程序不难发现，屏幕上显示的内容其实是COOKIE的内容，而第一次 访问时尚未设置COOKIE的值，因此不会有显示，第二次显示的是第一次设置的值。那么对应的HTTP消息头应该是什么样的呢？ 第一次请求时没什么不一样，略过 第一次返回时消息内容多了下面这一行： Set-Cookie: key=haha; expires=Sun, 31-Dec-2006 16:00:00 GMT; path=/ 很明显，key=haha表示键名为“key”的COOKIE的值为“haha”，后面是这则COOKIE的过时时间，由于我用的中文操做系统的时区是东八区，2007年1月1日0点对应的GMT时间就是2006年12月31日16点。 第二次再访问此网页时，发送的内容多了以下一行： Cookie: key=haha 它的内容就是刚才设的COOKIE的内容。可见，客户端在从服务器端获得COOKIE值之后就保存在硬盘上，再次访问时就会把它发送到服务器。发送时并无发送过时时间，由于服务器对过时时间并不关心，当COOKIE过时后浏览器就不会再发送它了。 如 果使用IE6.0浏览器而且禁用COOKIE功能，能够发现服务器端的set-cookie仍是有的，但客户端并不会接受它，也不会发送它。有些网站，特 别是在线投票网站经过记录COOKIE防止用户重复投票，破解很简单，只要用IE6浏览器并禁用COOKIE就能够了。也有的网站经过COOKIE值为某 值来判断用户是否合法，这种判断也很是容易经过手工构造HTTP消息头来欺骗，固然用HOSTS的方式也是能够欺骗的。 3 SESSION HTTP协议自己是无状态的，服务器和客户端都不保证用户访问期间链接会一直保 持，事实上保持链接是HTTP1.1才有的新内容，当客户端发送的消息头中有“Connection: Keep-Alive”时表示客户端浏览器支持保持链接的工做方式，但这个链接也会在一段时间没有请求后自动断开，以节省服务器资源。为了在服务器端维持 用户状态，SESSION就被发明出来了，如今各主流的动态网页制作工具都支持SESSION，但支持的方式不彻底相同，如下皆以ASP为例。 当用户请求一个ASP网页时，在返回的HTTP消息头中会有一行： Set-Cookie: ASPSESSIONIDCSQCRTBS=KOIPGIMBCOCBFMOBENDCAKDP; path=/ 服 务器经过COOKIE的方式告诉客户端你的SESSIONID是多少，在这里是“KOIPGIMBCOCBFMOBENDCAKDP”，而且服务器上保留 了和此SESSIONID相关的数据，当同一用户再次发送请求时，还会把这个COOKIE再发送回去，服务器端根据此ID找到此用户的数据，也就实现了服 务器端用户状态的保存。因此咱们用ASP编程时能够使用“session("name")=user”这样的方式保存用户信息。注意此COOKIE内容里 并无过时时间，这表示这是一个当关闭浏览器时当即过时的COOKIE，它不会被保存到硬盘上。这种工做方式比单纯用COOKIE的方式要安全不少，由于 在客户端并无什么能让咱们修改和欺骗的值，惟一的信息就是SESSIONID，而这个ID在浏览器关闭时会当即失效，除非别人能在你浏览网站期间或关闭 浏览器后很短期内知道此ID的值，才能作一些欺骗活动。由于服务器端判断SESSION过时的方式并非断开链接或关闭浏览器，而是经过用户手工结束 SESSION或等待超时，当用户关闭浏览器后的一段时间里SESSION尚未超时，因此这时若是知道了刚才的SESSIONID，仍是能够欺骗的。因 此最安全的办法仍是在离开网站以前手工结束SESSION，不少网站都提供“Logout”功能，它会经过设置SESSION中的值为已退出状态或让 SESSION当即过时从而起到安全的目的。 SESSION和COOKIE的方式各有优缺点。SESSION的优势是比较安全，不容易被欺骗，缺 点是过时时间短，若是用过在超过过时时间里没有向服务器发送任何信息，就会被认为超过过时了；COOKIE则相反，根据服务器端设置的超时时间，能够长时 间保留信息，即便关机再开机也可能保留状态，而安全性天然大打折扣。不少网站都提供两种验证方式相结合，若是用户临时用这台电脑访问此访问则须要输入用户 名和密码，不保存COOKIE；若是用户使用的是本身的我的电脑，则可让网站在本身硬盘上保留COOKIE，之后访问时就不须要从新输入用户名和密码 了。 4 POST 浏览器访问服务器经常使用的方式有GET和POST两种，GET方式只发送HTTP消息 头，没有消息体，也就是除了要GET的基本信息以外不向服务器提供其余信息，网页表单（FROM）的默认提交方式就是用GET方式，它会把全部向服务器提 交的信息都做为URL后面的参数，如a.asp?a=1&b=2这样的方式。而当要提交的数据量很大，或者所提交内容不但愿别人直接看到时，应该 使用POST方式。POST方式提交的数据是做为HTTP消息体存在的，例如，写一个网页表单： <form method=post> <input type=text name=text1> <input type=submit> </form> 访问此网页，并在表单中填入一个“haha”，而后提交，能够看到这次提交所发送的信息以下： POST /form.asp HTTP/1.1 Accept: */* Referer: http://localhost:8080/form.asp Accept-Language: zh-cn 海姹网（网址:http://www.seacha.com），标签：HTTP状态码完整介绍， HTTP,协议,状态码,seo Content-Type: application/x-www-form-urlencoded Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; InfoPath.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727) Host: localhost:8080 Content-Length: 10 Connection: Keep-Alive Cache-Control: no-cache Cookie: key=haha; ASPSESSIONIDCSQCRTBS=LOIPGIMBLMNOGCOBOMPJBOKP text1=haha 前 面关键字从“GET”变为了“POST”，Content-Type变成了“application/x-www-form-urlencoded”，后 面内容并没有大变化，只是多了一行：Content-Length: 10，表示提交的内容的长度。空行后面是消息体，内容就是表单中所填的内容。注意此时发送的内容只是“Name=Value”的形式，表单上其余的信息不 会被发送，因此想直接从服务器端取得list box中全部的list item是办不到的，除非在提交前用一段script把全部的item内容都连在一块儿放到一个隐含表单域中。 若是是用表单上传文件，状况就要复杂一些了，首先是表单声明中要加上一句话：enctype=’multipart/form-data’，表示这个表单将提交多段数据，并用HTML：input type=file来声明一个文件提交域。 表单内容以下： <form method=post enctype=’multipart/form-data’> <input type=text name=text1> <input type=file name=file1> <input type=submit> </form> 咱们为text1输入文字：hehe，为file1选择文件haha.txt，其内容为“ABCDEFG”，而后提交此表单。提交的彻底信息为： POST /form.asp HTTP/1.1 Accept: */* Referer: http://localhost:8080/form.asp Accept-Language: zh-cn Content-Type: multipart/form-data; boundary=—————————7d62bf2f9066c Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; InfoPath.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727) Host: localhost:8080 Content-Length: 337 Connection: Keep-Alive Cache-Control: no-cache Cookie: key=haha; ASPSESSIONIDCSQCRTBS=LOIPGIMBLMNOGCOBOMPJBOKP —————————–7d62bf2f9066c Content-Disposition: form-data; name="text1" hehe —————————–7d62bf2f9066c Content-Disposition: form-data; name="file1"; filename="H:\Documents and Settings\Administrator\桌面\haha.txt" Content-Type: text/plain ABCDEFG —————————–7d62bf2f9066c– 显然这个提交的信息要比前述的复杂不少。Content-Type变成了“multipart/form-data”，后面还多了一个 boundary，此值是为了区分POST的内容的区段用的，只要在内容中遇到了此值，就表示下面要开始一个新的区段了，每一个区段的内容相对独立。若是遇 到的是此值后面连着两个减号，则表示所有内容到此结束。每一个段也分为段头和段体两部分，用空行隔开，每段都有本身的类型和相关信息。如第一区段是 text1的值，它的名称是“text1”，值为“hehe”。第二段是文件内容，段首里代表了此文件域的名称“file1”和此文件在用户磁盘上的位 置，后面就是文件的内容。 若是咱们想要本身写一个上传文件组件来接收HTML表单传送的文件数据，那么最核心的任务就是解析此数据包，从中取得须要的信息。 理解HTTP消息头 （四） 服务器返回的消息 服务器返回的HTTP消息也分为消息头和消息体两部分。前面连载的第二篇里已经介绍了返回消息中常见返回代码的含义。对于非正常的返回代码的处理比较简单，只要照着要求去作就行了，而对于正常的返回代码（200），其处理方式就多种多样了。 1 Content-Type Content-Type是返回消息中很是重要的内容，它标识出这个返回内容的类型，其值为“主类型/子类型”的格式，例如最多见的就是 text/html，它的意思是说返回的内容是文本类型，这个文本又是HTML格式的。原则上浏览器会根据Content-Type来决定如何显示返回的 消息体内容。常见的内容类型有： text/html HTML文本 image/jpeg JPG图片 image/gif GIF图片 application/xml XML文档 audio/x-mpegurl MP3文件列表，若是安装了Winamp，则能够直接把它当面M3U文件来打开 更多的内容类型能够在注册表“HKCR\MIME\Database\Content Type”下看到 对于IE6浏览器来讲，若是Content-Type中的类型和实际的消息体类型不一致，那么它会根据内容中的类型来分析实际应该是什么类型，对于JPG、GIF等经常使用图片格式均可以正确的识别出来，而无论Content-Type中写的是什么。 如 果Content-Type中指定的是浏览器能够直接打开的类型，那么浏览器就会直接打开其内容显示出来，若是是被关联到其它应用程序的类型，这时就要查 找注册表中关于这种类型的注册状况，若是是容许直接打开而不须要询问的，就会直接调出这个关联的应用程序来打开这个文件，但若是是不容许直接打开的，就会 询问是否打开。对于没有关联到任何应用程序的类型，IE浏览器不知道它该如何打开，此时IE6就会把它当成XML来尝试打开。 2 Content-Disposition 若是用AddHeader的方法在HTTP消息头中加入Content-Disposition段，并指定其值为“attachment”，那 么不管这个文件是何类型，浏览器都会提示咱们下载此文件，由于此时它认为后面的消息体是一个“附件”，不须要由浏览器来处理了。例如，在ASP.Net中 写入以下语句： Response.AddHeader("Content-Disposition: attachment"); 请求此页面是获得的结果如： HTTP/1.1 200 OK Server: Microsoft-IIS/5.1 Date: Thu, 23 Mar 2006 07:54:53 GMT Content-Disposition: attachment Cache-Control: private Content-Type: text/html; charset=utf-8 …… 也 就是说，经过AddHeader函数能够为HTTP消息头加入咱们自定义的内容。使用这种方法能够强制让浏览器提示下载文件，即便这个文件是咱们已知的类 型，基因而HTML网页。若是想要让用户下载时提示一个默认的文件名，只须要在前面一句话后加上“filename=文件名”便可。例如： 海姹网（网址:http://www.seacha.com），标签：HTTP状态码完整介绍， HTTP,协议,状态码,seo Response.AddHeader("Content-Disposition: attachment; filename=mypage.htm"); 3 Content-Type与Content-Disposition 若是把Content-Type和Content-Disposition结合在一块儿使用会怎么样呢？ 打开一个网页时，浏览器会首先看是否有Content-Disposition: attachment这一项，若是有，不管Content-Type的值是什么，都会提示文件下载。 如 果指定了filename，就会提示默认的文件名为此文件名。注意到在IE6中除了“保存”按扭外还有“打开”按扭，此时打开文件的类型是由在 filename中指定的文件扩展名决定的，例如让filename=mypic.jpg，浏览器就会查找默认的图片查看器来打开此文件。 若是没 有指定filename，那么浏览器就根据Content-Type中的类型来决定文件的类型，例如Content-Type类型为image/gif， 那么就会去查找默认的看GIF图片的工具，而且设置此文件的名字为所请求的网页的主名（不带扩展名）加上对应于此文件类弄扩展名，例如请求的 mypage.aspx，就会自动变成mypage.gif。若是并无指定Content-Type值，那么就默认它为“text/html”，而且保 存的文件名就是所请求的网页文件名。 但若是没有指定Content-Disposition，那么就和前面关于Content-Type中所讨论的状况是同样的了。 4 Cache 返回消息中的Cache用于指定网页缓存。咱们常常能够看到这样的状况，打开一个网页时速度不快，但再次打开时就会快不少，缘由是浏览器已经对此页 面进行了缓存，那么在同一浏览器窗口中再次打开此页时不会从新从服务器端获取。网页的缓存是由HTTP消息头中的“Cache-control”来控制 的，常见的取值有private、no-cache、max-age、must-revalidate等，默认为private。其做用根据不一样的从新浏 览方式分为如下几种状况： （1） 打开新窗口 若是指定cache-control的值为private、no-cache、must-revalidate，那么打开新窗口访问时都会从新访问服务器。而若是指定了max-age值，那么在此值内的时间里就不会从新访问服务器，例如： Cache-control: max-age=5 表示当访问此网页后的5秒内再次访问不会去服务器 （2） 在地址栏回车 若是值为private或must-revalidate（和网上说的不同），则只有第一次访问时会访问服务器，之后就再也不访问。若是值为no-cache，那么每次都会访问。若是值为max-age，则在过时以前不会重复访问。 （3） 按后退按扭 若是值为private、must-revalidate、max-age，则不会重访问，而若是为no-cache，则每次都重复访问 （4） 按刷新按扭 不管为什么值，都会重复访问 当指定Cache-control值为“no-cache”时，访问此页面不会在Internet临时文章夹留下页面备份。 另外，经过指定“Expires”值也会影响到缓存。例如，指定Expires值为一个早已过去的时间，那么访问此网时若重复在地址栏按回车，那么每次都会重复访问： Expires: Fri, 31 Dec 1999 16:00:00 GMT 在ASP中，能够经过Response对象的Expires、ExpiresAbsolute属性控制Expires值；经过Response对象的CacheControl属性控制Cache-control的值，例如： Response.ExpiresAbsolute = #2000-1-1# ’ 指定绝对的过时时间，这个时间用的是服务器当地时间，会被自动转换为GMT时间 Response.Expires = 20  ’ 指定相对的过时时间，以分钟为单位，表示从当前时间起过多少分钟过时。 Response.CacheControl = "no-cache" HTTP状态码（HTTP Status Code）是用以表示网页服务器HTTP响应状态的3位数字代码。它由RFC 2616规范定义的，并获得RFC 251八、RFC 281七、RFC 229五、RFC 277四、RFC 4918等规范扩展。 全部状态码的第一个数字表明了响应的五种状态之一。 目录  1 1xx消息 2 2xx成功 3 3xx重定向 4 4xx请求错误 5 5xx服务器错误 6 参考 7 引用文献 8 外部连接 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状态码的响应应当在返回的实体中包含一些指示处理当前状态的信息，以及指向处理状态监视器或状态预测的指针，以便用户可以估计操做是否已经完成。 海姹网（网址:http://www.seacha.com），标签：HTTP状态码完整介绍， HTTP,协议,状态码,seo 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的超连接及简短说明。 海姹网（网址:http://www.seacha.com），标签：HTTP状态码完整介绍， HTTP,协议,状态码,seo 若是这不是一个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请求，那么浏览器禁止自动进行重定向，除非获得用户的确认，由于请求的条件可能所以发生变化。 4xx 请求错误 这类的状态码表明了客户端看起来可能发生了错误，妨碍了服务器的处理。除非响应的是一个HEAD请求，不然服务器就应该返回一个解释当前错误情况的实体，以及这是临时的仍是永久性的情况。这些状态码适用于任何请求方法。浏览器应当向用户显示任何包含在此类错误响应中的实体内容。 若是错误发生时客户端正在传送数据，那么使用TCP的服务器实现应当仔细确保在关闭客户端与服务器之间的链接以前，客户端已经收到了包含错误信息的数据包。若是客户端在收到错误信息后继续向服务器发送数据，服务器的TCP栈将向客户端发送一个重置数据包，以清除该客户端全部还未识别的输入缓冲，以避免这些数据被服务器上的应用程序读取并干扰后者。 400 Bad Request 因为包含语法错误，当前请求没法被服务器理解。除非进行修改，不然客户端不该该重复提交这个请求。 401 Unauthorized 当前请求须要用户验证。该响应必须包含一个适用于被请求资源的WWW-Authenticate信息头用以询问用户信息。客户端能够重复提交一个包含恰当的Authorization头信息的请求。若是当前请求已经包含了Authorization证书，那么401响应表明着服务器验证已经拒绝了那些证书。若是401响应包含了与前一个响应相同的身份验证询问，且浏览器已经至少尝试了一次验证，那么浏览器应当向用户展现响应中包含的实体信息，由于这个实体信息中可能包含了相关诊断信息。参见RFC 2617。 402 Payment Required 该状态码是为了未来可能的需求而预留的。 403 Forbidden 服务器已经理解请求，可是拒绝执行它。与401响应不一样的是，身份验证并不能提供任何帮助，并且这个请求也不该该被重复提交。若是这不是一个HEAD请求，并且服务器但愿可以讲清楚为什么请求不能被执行，那么就应该在实体内描述拒绝的缘由。固然服务器也能够返回一个404响应，假如它不但愿让客户端得到任何信息。 海姹网（网址:http://www.seacha.com），标签：HTTP状态码完整介绍， HTTP,协议,状态码,seo 404 Not Found 请求失败，请求所但愿获得的资源未被在服务器上发现。没有信息可以告诉用户这个情况究竟是暂时的仍是永久的。假如服务器知道状况的话，应当使用410状态码来告知旧资源由于某些内部的配置机制问题，已经永久的不可用，并且没有任何能够跳转的地址。404这个状态码被普遍应用于当服务器不想揭示到底为什么请求被拒绝或者没有其余适合的响应可用的状况下。 405 Method Not Allowed 请求行中指定的请求方法不能被用于请求相应的资源。该响应必须返回一个Allow头信息用以表示出当前资源可以接受的请求方法的列表。 鉴于PUT，DELETE方法会对服务器上的资源进行写操做，于是绝大部分的网页服务器都不支持或者在默认配置下不容许上述请求方法，对于此类请求均会返回405错误。 406 Not Acceptable 请求的资源的内容特性没法知足请求头中的条件，于是没法生成响应实体。 除非这是一个HEAD请求，不然该响应就应当返回一个包含可让用户或者浏览器从中选择最合适的实体特性以及地址列表的实体。实体的格式由Content-Type头中定义的媒体类型决定。浏览器能够根据格式及自身能力自行做出最佳选择。可是，规范中并无定义任何做出此类自动选择的标准。 407 Proxy Authentication Required 与401响应相似，只不过客户端必须在代理服务器上进行身份验证。代理服务器必须返回一个Proxy-Authenticate用以进行身份询问。客户端能够返回一个Proxy-Authorization信息头用以验证。参见RFC 2617。 408 Request Timeout 请求超时。客户端没有在服务器预备等待的时间内完成一个请求的发送。客户端能够随时再次提交这一请求而无需进行任何更改。 409 Conflict 因为和被请求的资源的当前状态之间存在冲突，请求没法完成。这个代码只容许用在这样的状况下才能被使用：用户被认为可以解决冲突，而且会从新提交新的请求。该响应应当包含足够的信息以便用户发现冲突的源头。 冲突一般发生于对PUT请求的处理中。例如，在采用版本检查的环境下，某次PUT提交的对特定资源的修改请求所附带的版本信息与以前的某个（第三方）请求向冲突，那么此时服务器就应该返回一个409错误，告知用户请求没法完成。此时，响应实体中极可能会包含两个冲突版本之间的差别比较，以便用户从新提交归并之后的新版本。 410 Gone 被请求的资源在服务器上已经再也不可用，并且没有任何已知的转发地址。这样的情况应当被认为是永久性的。若是可能，拥有连接编辑功能的客户端应当在得到用户许可后删除全部指向这个地址的引用。若是服务器不知道或者没法肯定这个情况是不是永久的，那么就应该使用404状态码。除非额外说明，不然这个响应是可缓存的。 410响应的目的主要是帮助网站管理员维护网站，通知用户该资源已经再也不可用，而且服务器拥有者但愿全部指向这个资源的远端链接也被删除。这类事件在限时、增值服务中很广泛。一样，410响应也被用于通知客户端在当前服务器站点上，本来属于某个我的的资源已经再也不可用。固然，是否须要把全部永久不可用的资源标记为'410 Gone'，以及是否须要保持此标记多长时间，彻底取决于服务器拥有者。 411 Length Required 服务器拒绝在没有定义Content-Length头的状况下接受请求。在添加了代表请求消息体长度的有效Content-Length头以后，客户端能够再次提交该请求。 412 Precondition Failed 服务器在验证在请求的头字段中给出先决条件时，没能知足其中的一个或多个。这个状态码容许客户端在获取资源时在请求的元信息（请求头字段数据）中设置先决条件，以此避免该请求方法被应用到其但愿的内容之外的资源上。 413 Request Entity Too Large 服务器拒绝处理当前请求，由于该请求提交的实体数据大小超过了服务器愿意或者可以处理的范围。此种状况下，服务器能够关闭链接以避免客户端继续发送此请求。 若是这个情况是临时的，服务器应当返回一个Retry-After的响应头，以告知客户端能够在多少时间之后从新尝试。 414 Request-URI Too Long 请求的URI长度超过了服务器可以解释的长度，所以服务器拒绝对该请求提供服务。这比较少见，一般的状况包括： 本应使用POST方法的表单提交变成了GET方法，致使查询字符串（Query String）过长。 重定向URI“黑洞”，例如每次重定向把旧的URI做为新的URI的一部分，致使在若干次重定向后URI超长。 客户端正在尝试利用某些服务器中存在的安全漏洞攻击服务器。这类服务器使用固定长度的缓冲读取或操做请求的URI，当GET后的参数超过某个数值后，可能会产生缓冲区溢出，致使任意代码被执行[1]。没有此类漏洞的服务器，应当返回414状态码。 415 Unsupported Media Type 对于当前请求的方法和所请求的资源，请求中提交的实体并非服务器中所支持的格式，所以请求被拒绝。 416 Requested Range Not Satisfiable 若是请求中包含了Range请求头，而且Range中指定的任何数据范围都与当前资源的可用范围不重合，同时请求中又没有定义If-Range请求头，那么服务器就应当返回416状态码。 假如Range使用的是字节范围，那么这种状况就是指请求指定的全部数据范围的首字节位置都超过了当前资源的长度。服务器也应当在返回416状态码的同时，包含一个Content-Range实体头，用以指明当前资源的长度。这个响应也被禁止使用multipart/byteranges做为其Content-Type。 417 Expectation Failed 在请求头Expect中指定的预期内容没法被服务器知足，或者这个服务器是一个代理服务器，它有明显的证据证实在当前路由的下一个节点上，Expect的内容没法被知足。 418 I'm a teapot 本操做码是在1998年做为IETF的传统愚人节笑话, 在RFC 2324 超文本咖啡壶控制协议中定义的，并不须要在真实的HTTP服务器中定义。 海姹网（网址:http://www.seacha.com），标签：HTTP状态码完整介绍， HTTP,协议,状态码,seo 421 There are too many connections from your internet address 从当前客户端所在的IP地址到服务器的链接数超过了服务器许可的最大范围。一般，这里的IP地址指的是从服务器上看到的客户端地址（好比用户的网关或者代理服务器地址）。在这种状况下，链接数的计算可能涉及到不止一个终端用户。 422 Unprocessable Entity 请求格式正确，可是因为含有语义错误，没法响应。（RFC 4918 WebDAV） 423 Locked 当前资源被锁定。（RFC 4918 WebDAV） 424 Failed Dependency 因为以前的某个请求发生的错误，致使当前请求失败，例如PROPPATCH。（RFC 4918 WebDAV） 425 Unordered Collection 在WebDav Advanced Collections草案中定义，可是未出如今《WebDAV顺序集协议》（RFC 3658）中。 426 Upgrade Required 客户端应当切换到TLS/1.0。（RFC 2817） 449 Retry With 由微软扩展，表明请求应当在执行完适当的操做后进行重试。 5xx 服务器错误 这类状态码表明了服务器在处理请求的过程当中有错误或者异常状态发生，也有多是服务器意识到以当前的软硬件资源没法完成对请求的处理。除非这是一个HEAD请求，不然服务器应当包含一个解释当前错误状态以及这个情况是临时的仍是永久的解释信息实体。浏览器应当向用户展现任何在当前响应中被包含的实体。 这些状态码适用于任何响应方法。 500 Internal Server Error 服务器遇到了一个不曾预料的情况，致使了它没法完成对请求的处理。通常来讲，这个问题都会在服务器的程序码出错时出现。 501 Not Implemented 服务器不支持当前请求所须要的某个功能。当服务器没法识别请求的方法，而且没法支持其对任何资源的请求。 502 Bad Gateway 做为网关或者代理工做的服务器尝试执行请求时，从上游服务器接收到无效的响应。 503 Service Unavailable 因为临时的服务器维护或者过载，服务器当前没法处理请求。这个情况是临时的，而且将在一段时间之后恢复。若是可以预计延迟时间，那么响应中能够包含一个Retry-After头用以标明这个延迟时间。若是没有给出这个Retry-After信息，那么客户端应当以处理500响应的方式处理它。 504 Gateway Timeout 做为网关或者代理工做的服务器尝试执行请求时，未能及时从上游服务器（URI标识出的服务器，例如HTTP、FTP、LDAP）或者辅助服务器（例如DNS）收到响应。 注意：某些代理服务器在DNS查询超时时会返回400或者500错误 505 HTTP Version Not Supported 服务器不支持，或者拒绝支持在请求中使用的HTTP版本。这暗示着服务器不能或不肯使用与客户端相同的版本。响应中应当包含一个描述了为什么版本不被支持以及服务器支持哪些协议的实体。 506 Variant Also Negotiates 由《透明内容协商协议》（RFC 2295）扩展，表明服务器存在内部配置错误：被请求的协商变元资源被配置为在透明内容协商中使用本身，所以在一个协商处理中不是一个合适的重点。 507 Insufficient Storage 服务器没法存储完成请求所必须的内容。这个情况被认为是临时的。WebDAV（RFC 4918） 509 Bandwidth Limit Exceeded 服务器达到带宽限制。这不是一个官方的状态码，可是仍被普遍使用。 510 Not Extended 获取资源所须要的策略并无没知足。（RFC 2774） 引言                                         HTTP是一个属于应用层的面 向对象的协议，因为其简捷、快速的方式，适用于分布式超媒体信息系统。它于1990年提出，通过几年的使用与发展，获得不断地完善和扩展。目前在WWW中 使用的是HTTP/1.0的第六版，HTTP/1.1的规范化工做正在进行之中，并且HTTP-NG(Next Generation of HTTP)的建议已经提出。 HTTP协议的主要特色可归纳以下： 1.支持客户/服务器模式。 2.简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法经常使用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不一样。因为HTTP协议简单，使得HTTP服务器的程序规模小，于是通讯速度很快。 3.灵活：HTTP容许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。 4.无链接：无链接的含义是限制每次链接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开链接。采用这种方式能够节省传输时间。 5.无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺乏状态意味着若是后续处理须要前面的信息，则它必须重传，这样可能致使每次链接传送的数据量增大。另外一方面，在服务器不须要先前信息时它的应答就较快。 1、HTTP协议详解之URL篇     http（超文本传输协议）是一个基于请求与响应模式的、无状态的、应用层的协议，常基于TCP的链接方式，HTTP1.1版本中给出一种持续链接的机制，绝大多数的Web开发，都是构建在HTTP协议之上的Web应用。 HTTP URL (URL是一种特殊类型的URI，包含了用于查找某个资源的足够的信息)的格式以下： http://host[":"port][abs_path] http 表示要经过HTTP协议来定位网络资源；host表示合法的Internet主机域名或者IP地址；port指定一个端口号，为空则使用缺省端口 80；abs_path指定请求资源的URI；若是URL中没有给出abs_path，那么当它做为请求URI时，必须以“/”的形式给出，一般这个工做 浏览器自动帮咱们完成。 eg: 一、输入：www.guet.edu.cn 浏览器自动转换成：http://www.guet.edu.cn/ 二、http:192.168.0.116:8080/index.jsp  海姹网（网址:http://www.seacha.com），标签：HTTP状态码完整介绍， HTTP,协议,状态码,seo 2、HTTP协议详解之请求篇     http请求由三部分组成，分别是：请求行、消息报头、请求正文 一、请求行以一个方法符号开头，以空格分开，后面跟着请求的URI和协议的版本，格式以下：Method Request-URI HTTP-Version CRLF   其中 Method表示请求方法；Request-URI是一个统一资源标识符；HTTP-Version表示请求的HTTP协议版本；CRLF表示回车和换行（除了做为结尾的CRLF外，不容许出现单独的CR或LF字符）。 请求方法（全部方法全为大写）有多种，各个方法的解释以下： GET     请求获取Request-URI所标识的资源 POST    在Request-URI所标识的资源后附加新的数据 HEAD    请求获取由Request-URI所标识的资源的响应消息报头 PUT     请求服务器存储一个资源，并用Request-URI做为其标识 DELETE  请求服务器删除Request-URI所标识的资源 TRACE   请求服务器回送收到的请求信息，主要用于测试或诊断 CONNECT 保留未来使用 OPTIONS 请求查询服务器的性能，或者查询与资源相关的选项和需求 应用举例： GET方法：在浏览器的地址栏中输入网址的方式访问网页时，浏览器采用GET方法向服务器获取资源，eg:GET /form.html HTTP/1.1 (CRLF) POST方法要求被请求服务器接受附在请求后面的数据，经常使用于提交表单。 eg：POST /reg.jsp HTTP/ (CRLF) Accept:image/gif,image/x-xbit,... (CRLF) ... HOST:www.guet.edu.cn (CRLF) Content-Length:22 (CRLF) Connection:Keep-Alive (CRLF) Cache-Control:no-cache (CRLF) (CRLF)         //该CRLF表示消息报头已经结束，在此以前为消息报头 user=jeffrey&pwd=1234  //此行如下为提交的数据 HEAD方法与GET方法几乎是同样的，对于HEAD请求的回应部分来讲，它的HTTP头部中包含的 信息与经过GET请求所获得的信息是相同的。利用这个方法，没必要传输整个资源内容，就能够获得Request-URI所标识的资源的信息。该方法经常使用于测 试超连接的有效性，是否能够访问，以及最近是否更新。 二、请求报头后述 三、请求正文(略)  3、HTTP协议详解之响应篇     在接收和解释请求消息后，服务器返回一个HTTP响应消息。 HTTP响应也是由三个部分组成，分别是：状态行、消息报头、响应正文 一、状态行格式以下： HTTP-Version Status-Code Reason-Phrase CRLF 其中，HTTP-Version表示服务器HTTP协议的版本；Status-Code表示服务器发回的响应状态代码；Reason-Phrase表示状态代码的文本描述。 状态代码有三位数字组成，第一个数字定义了响应的类别，且有五种可能取值： 1xx：指示信息--表示请求已接收，继续处理 2xx：成功--表示请求已被成功接收、理解、接受 3xx：重定向--要完成请求必须进行更进一步的操做 4xx：客户端错误--请求有语法错误或请求没法实现 5xx：服务器端错误--服务器未能实现合法的请求 常见状态代码、状态描述、说明： 200 OK      //客户端请求成功 400 Bad Request  //客户端请求有语法错误，不能被服务器所理解 401 Unauthorized //请求未经受权，这个状态代码必须和WWW-Authenticate报                 //头域一块儿使用  403 Forbidden  //服务器收到请求，可是拒绝提供服务 404 Not Found  //请求资源不存在，eg：输入了错误的URL 500 Internal Server Error //服务器发生不可预期的错误 503 Server Unavailable  //服务器当前不能处理客户端的请求，一段时间后，                         //可能恢复正常 eg：HTTP/1.1 200 OK （CRLF） 二、响应报头后述 三、响应正文就是服务器返回的资源的内容  4、HTTP协议详解之消息报头篇     HTTP消息由客户端到服务器的请求和服务器到客户端的响应组成。请求消息和响应消息都是由开始行（对于请求消息，开始行就是请求行，对于响应消息，开始行就是状态行），消息报头（可选），空行（只有CRLF的行），消息正文（可选）组成。 HTTP消息报头包括普通报头、请求报头、响应报头、实体报头。 每个报头域都是由名字+“：”+空格+值 组成，消息报头域的名字是大小写无关的。 一、普通报头 在普通报头中，有少数报头域用于全部的请求和响应消息，但并不用于被传输的实体，只用于传输的消息。 eg： Cache-Control   用于指定缓存指令，缓存指令是单向的（响应中出现的缓存指令在请求中未必会出现），且是独立的（一个消息的缓存指令不会影响另外一个消息处理的缓存机制），HTTP1.0使用的相似的报头域为Pragma。 请求时的缓存指令包括：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、s-maxage. eg：为了指示IE浏览器（客户端）不要缓存页面，服务器端的JSP程序能够编写以下：response.sehHeader("Cache-Control","no-cache"); //response.setHeader("Pragma","no-cache");做用至关于上述代码，一般二者//合用 这句代码将在发送的响应消息中设置普通报头域：Cache-Control:no-cache Date普通报头域表示消息产生的日期和时间 Connection普通报头域容许发送指定链接的选项。例如指定链接是连续，或者指定“close”选项，通知服务器，在响应完成后，关闭链接 二、请求报头 请求报头容许客户端向服务器端传递请求的附加信息以及客户端自身的信息。 海姹网（网址:http://www.seacha.com），标签：HTTP状态码完整介绍， HTTP,协议,状态码,seo 经常使用的请求报头 Accept Accept请求报头域用于指定客户端接受哪些类型的信息。eg：Accept：image/gif，代表客户端但愿接受GIF图象格式的资源；Accept：text/html，代表客户端但愿接受html文本。 Accept-Charset Accept-Charset请求报头域用于指定客户端接受的字符集。eg：Accept-Charset:iso-8859-1,gb2312.若是在请求消息中没有设置这个域，缺省是任何字符集均可以接受。 Accept-Encoding Accept-Encoding请求报头域相似于Accept，可是它是用于指定可接受的内容编码。eg：Accept-Encoding:gzip.deflate.若是请求消息中没有设置这个域服务器假定客户端对各类内容编码均可以接受。 Accept-Language Accept-Language请求报头域相似于Accept，可是它是用于指定一种天然语言。eg：Accept-Language:zh-cn.若是请求消息中没有设置这个报头域，服务器假定客户端对各类语言均可以接受。 Authorization Authorization请求报头域主要用于证实客户端有权查看某个资源。当浏览器访问一个页面时，若是收到服务器的响应代码为401（未受权），能够发送一个包含Authorization请求报头域的请求，要求服务器对其进行验证。 Host（发送请求时，该报头域是必需的） Host请求报头域主要用于指定被请求资源的Internet主机和端口号，它一般从HTTP URL中提取出来的，eg： 咱们在浏览器中输入：http://www.guet.edu.cn/index.html 浏览器发送的请求消息中，就会包含Host请求报头域，以下： Host：www.guet.edu.cn 此处使用缺省端口号80，若指定了端口号，则变成：Host：www.guet.edu.cn:指定端口号 User-Agent 我 们上网登录论坛的时候，每每会看到一些欢迎信息，其中列出了你的操做系统的名称和版本，你所使用的浏览器的名称和版本，这每每让不少人感到很神奇，实际 上，服务器应用程序就是从User-Agent这个请求报头域中获取到这些信息。User-Agent请求报头域容许客户端将它的操做系统、浏览器和其它 属性告诉服务器。不过，这个报头域不是必需的，若是咱们本身编写一个浏览器，不使用User-Agent请求报头域，那么服务器端就没法得知咱们的信息 了。 请求报头举例： GET /form.html HTTP/1.1 (CRLF) Accept:image/gif,image/x-xbitmap,image/jpeg,application/x-shockwave-flash,application/vnd.ms-excel,application/vnd.ms-powerpoint,application/msword,*/* (CRLF) Accept-Language:zh-cn (CRLF) Accept-Encoding:gzip,deflate (CRLF) If-Modified-Since:Wed,05 Jan 2007 11:21:25 GMT (CRLF) If-None-Match:W/"80b1a4c018f3c41:8317" (CRLF) User-Agent:Mozilla/4.0(compatible;MSIE6.0;Windows NT 5.0) (CRLF) Host:www.guet.edu.cn (CRLF) Connection:Keep-Alive (CRLF) (CRLF) 三、响应报头 响应报头容许服务器传递不能放在状态行中的附加响应信息，以及关于服务器的信息和对Request-URI所标识的资源进行下一步访问的信息。 经常使用的响应报头 Location Location响应报头域用于重定向接受者到一个新的位置。Location响应报头域经常使用在更换域名的时候。 Server Server响应报头域包含了服务器用来处理请求的软件信息。与User-Agent请求报头域是相对应的。下面是 Server响应报头域的一个例子： Server：Apache-Coyote/1.1 WWW-Authenticate WWW-Authenticate响应报头域必须被包含在401（未受权的）响应消息中，客户端收到401响应消息时候，并发送Authorization报头域请求服务器对其进行验证时，服务端响应报头就包含该报头域。 eg：WWW-Authenticate:Basic realm="Basic Auth Test!"  //能够看出服务器对请求资源采用的是基本验证机制。 四、实体报头 请求和响应消息均可以传送一个实体。一个实体由实体报头域和实体正文组成，但并非说实体报头域和实体正文要在一块儿发送，能够只发送实体报头域。实体报头定义了关于实体正文（eg：有无实体正文）和请求所标识的资源的元信息。 经常使用的实体报头 Content-Encoding Content- Encoding实体报头域被用做媒体类型的修饰符，它的值指示了已经被应用到实体正文的附加内容的编码，于是要得到Content-Type报头域中所 引用的媒体类型，必须采用相应的解码机制。Content-Encoding这样用于记录文档的压缩方法，eg：Content- Encoding：gzip Content-Language Content-Language实体报头域描述了资源所用的天然语言。没有设置该域则认为实体内容将提供给全部的语言阅读 者。eg：Content-Language:da Content-Length Content-Length实体报头域用于指明实体正文的长度，以字节方式存储的十进制数字来表示。 Content-Type Content-Type实体报头域用语指明发送给接收者的实体正文的媒体类型。eg： Content-Type:text/html;charset=ISO-8859-1 Content-Type:text/html;charset=GB2312 Last-Modified Last-Modified实体报头域用于指示资源的最后修改日期和时间。 Expires Expires 实体报头域给出响应过时的日期和时间。为了让代理服务器或浏览器在一段时间之后更新缓存中(再次访问曾访问过的页面时，直接从缓存中加载，缩短响应时间和 下降服务器负载)的页面，咱们能够使用Expires实体报头域指定页面过时的时间。eg：Expires：Thu，15 Sep 2006 16:23:12 GMT HTTP1.1的客户端和缓存必须将其余非法的日期格式（包括0）看做已通过期。eg：为了让浏览器不要缓存页面，咱们也能够利用Expires实体报头域，设置为0，jsp中程序以下：response.setDateHeader("Expires","0"); 5、利用telnet观察http协议的通信过程     实验目的及原理：     利用MS的telnet工具，经过手动输入http请求信息的方式，向服务器发出请求，服务器接收、解释和接受请求后，会返回一个响应，该响应会在telnet窗口上显示出来，从而从感性上加深对http协议的通信过程的认识。 海姹网（网址:http://www.seacha.com），标签：HTTP状态码完整介绍， HTTP,协议,状态码,seo     实验步骤： 一、打开telnet 1.1 打开telnet 运行-->cmd-->telnet 1.2 打开telnet回显功能 set localecho 二、链接服务器并发送请求 2.1 open www.guet.edu.cn 80  //注意端口号不能省略     HEAD /index.asp HTTP/1.0     Host:www.guet.edu.cn         /*咱们能够变换请求方法,请求桂林电子主页内容,输入消息以下*/     open www.guet.edu.cn 80          GET /index.asp HTTP/1.0  //请求资源的内容     Host:www.guet.edu.cn   2.2 open www.sina.com.cn 80  //在命令提示符号下直接输入telnet www.sina.com.cn 80     HEAD /index.asp HTTP/1.0     Host:www.sina.com.cn 3 实验结果： 3.1 请求信息2.1获得的响应是: HTTP/1.1 200 OK                                              //请求成功 Server: Microsoft-IIS/5.0                                    //web服务器 Date: Thu,08 Mar 200707:17:51 GMT Connection: Keep-Alive                                  Content-Length: 23330 Content-Type: text/html Expries: Thu,08 Mar 2007 07:16:51 GMT Set-Cookie: ASPSESSIONIDQAQBQQQB=BEJCDGKADEDJKLKKAJEOIMMH; path=/ Cache-control: private //资源内容省略 3.2 请求信息2.2获得的响应是: HTTP/1.0 404 Not Found       //请求失败 Date: Thu, 08 Mar 2007 07:50:50 GMT Server: Apache/2.0.54 <Unix> Last-Modified: Thu, 30 Nov 2006 11:35:41 GMT ETag: "6277a-415-e7c76980" Accept-Ranges: bytes X-Powered-By: mod_xlayout_jh/0.0.1vhs.markII.remix Vary: Accept-Encoding Content-Type: text/html X-Cache: MISS from zjm152-78.sina.com.cn Via: 1.0 zjm152-78.sina.com.cn:80<squid/2.6.STABLES-20061207> X-Cache: MISS from th-143.sina.com.cn Connection: close 失去了跟主机的链接 按任意键继续... 4 .注意事项：一、出现输入错误，则请求不会成功。           二、报头域不分大小写。           三、更深一步了解HTTP协议，能够查看RFC2616，在http://www.letf.org/rfc上找到该文件。           四、开发后台程序必须掌握http协议 6、HTTP协议相关技术补充     一、基础：     高层协议有：文件传输协议FTP、电子邮件传输协议SMTP、域名系统服务DNS、网络新闻传输协议NNTP和HTTP协议等 中 介由三种：代理(Proxy)、网关(Gateway)和通道(Tunnel)，一个代理根据URI的绝对格式来接受请求，重写所有或部分消息，经过 URI的标识把已格式化过的请求发送到服务器。网关是一个接收代理，做为一些其它服务器的上层，而且若是必须的话，能够把请求翻译给下层的服务器协议。一 个通道做为不改变消息的两个链接之间的中继点。当通信须要经过一个中介(例如：防火墙等)或者是中介不能识别消息的内容时，通道常常被使用。      代理(Proxy)：一个中间程序，它能够充当一个服务器，也能够充当一个客户机，为其它客户机创建请求。请求是经过可能的翻译在内部或通过传递到其它的 服务器中。一个代理在发送请求信息以前，必须解释而且若是可能重写它。代理常常做为经过防火墙的客户机端的门户，代理还能够做为一个帮助应用来经过协议处 理没有被用户代理完成的请求。 网关(Gateway)：一个做为其它服务器中间媒介的服务器。与代理不一样的是，网关接受请求就好象对被请求的资源来讲它就是源服务器；发出请求的客户机并无意识到它在同网关打交道。 网关常常做为经过防火墙的服务器端的门户，网关还能够做为一个协议翻译器以便存取那些存储在非HTTP系统中的资源。     通道(Tunnel)：是做为两个链接中继的中介程序。一旦激活，通道便被认为不属于HTTP通信，尽管通道多是被一个HTTP请求初始化的。当被中继 的链接两端关闭时，通道便消失。当一个门户(Portal)必须存在或中介(Intermediary)不能解释中继的通信时通道被常用。 二、协议分析的优点—HTTP分析器检测网络攻击 以模块化的方式对高层协议进行分析处理，将是将来入侵检测的方向。 HTTP及其代理的经常使用端口80、3128和8080在network部分用port标签进行了规定 三、HTTP协议Content Lenth限制漏洞致使拒绝服务攻击 使 用POST方法时，能够设置ContentLenth来定义须要传送的数据长度，例如ContentLenth:999999999，在传送完成前，内 存不会释放，攻击者能够利用这个缺陷，连续向WEB服务器发送垃圾数据直至WEB服务器内存耗尽。这种攻击方法基本不会留下痕迹。 http://www.cnpaf.net/Class/HTTP/0532918532667330.html 四、利用HTTP协议的特性进行拒绝服务攻击的一些构思 服务器端忙于处理攻击者伪造的TCP链接请求而无暇理睬客户的正常请求（毕竟客户端的正常请求比率很是之小），此时从正常客户的角度看来，服务器失去响应，这种状况咱们称做：服务器端受到了SYNFlood攻击（SYN洪水攻击）。 而Smurf、TearDrop等是利用ICMP报文来Flood和IP碎片攻击的。本文用“正常链接”的方法来产生拒绝服务攻击。 19 端口在早期已经有人用来作Chargen攻击了，即Chargen_Denial_of_Service，可是！他们用的方法是在两台Chargen 服务器之间产生UDP链接，让服务器处理过多信息而DOWN掉，那么，干掉一台WEB服务器的条件就必须有2个：1.有Chargen服务2.有HTTP 服务 海姹网（网址:http://www.seacha.com），标签：HTTP状态码完整介绍， HTTP,协议,状态码,seo 方法：攻击者伪造源IP给N台Chargen发送链接请求（Connect），Chargen接收到链接后就会返回每秒72字节的字符流（实际上根据网络实际状况，这个速度更快）给服务器。 五、Http指纹识别技术    Http指纹识别的原理大体上也是相同的：记录不一样服务器对Http协议执行中的微小差异进行识别.Http指纹识别比TCP/IP堆栈指纹识别复杂许 多,理由是定制Http服务器的配置文件、增长插件或组件使得更改Http的响应信息变的很容易,这样使得识别变的困难；然而定制TCP/IP堆栈的行为 须要对核心层进行修改,因此就容易识别.       要让服务器返回不一样的Banner信息的设置是很简单的,象Apache这样的开放源代码的Http服务器,用户能够在源代码里修改Banner信息,然 后重起Http服务就生效了；对于没有公开源代码的Http服务器好比微软的IIS或者是Netscape,能够在存放Banner信息的Dll文件中修 改,相关的文章有讨论的,这里再也不赘述,固然这样的修改的效果仍是不错的.另一种模糊Banner信息的方法是使用插件。 经常使用测试请求： 1：HEAD/Http/1.0发送基本的Http请求 2：DELETE/Http/1.0发送那些不被容许的请求,好比Delete请求 3：GET/Http/3.0发送一个非法版本的Http协议请求 4：GET/JUNK/1.0发送一个不正确规格的Http协议请求 Http指纹识别工具Httprint,它经过运用统计学原理,组合模糊的逻辑学技术,能颇有效的肯定Http服务器的类型.它能够被用来收集和分析不一样Http服务器产生的签名。 六、其余：为了提升用户使用浏览器时的性能，现代浏览器还支持并发的访问方式，浏览一个网页时同时创建多个链接，以迅速得到一个网页上的多个图标，这样能更快速完成整个网页的传输。 HTTP1.1中提供了这种持续链接的方式，而下一代HTTP协议：HTTP-NG更增长了有关会话控制、丰富的内容协商等方式的支持，来提供 更高效率的链接。 RFC 6585 最近刚刚发布，该文档描述了 4 个新的 HTTP 状态码。 HTTP 协议还在变化？是的，HTTP 协议一直在演变，新的状态码对于开发 REST 服务或者说是基于 HTTP 的服务很是有用，下面咱们为你详细介绍这四个新的状态码以及是否应该使用。 428 Precondition Required (要求先决条件) 先决条件是客户端发送 HTTP 请求时，若是想要请求能成功必须知足一些预设的条件。 一个好的例子就是 If-None-Match 头，常常在 GET 请求中使用，若是指定了 If-None-Match ，那么客户端只在响应中的 ETag 改变后才会从新接收回应。 先决条件的另一个例子就是 If-Match 头，这个通常用在 PUT 请求上用于指示只更新没被改变的资源，这在多个客户端使用 HTTP 服务时用来防止彼此间不会覆盖相同内容。 当服务器端使用 428 Precondition Required 状态码时，表示客户端必须发送上述的请求头才能执行请求，这个方法为服务器提供一种有效的方法来阻止 'lost update' 问题。 429 Too Many Requests (太多请求) 当你须要限制客户端请求某个服务数量时，该状态码就颇有用，也就是请求速度限制。 在此以前，有一些相似的状态码，例如 '509 Bandwidth Limit Exceeded'. Twitter 使用 420 （这不是HTTP定义的状态码） 若是你但愿限制客户端对服务的请求数，可以使用 429 状态码，同时包含一个 Retry-After 响应头用于告诉客户端多长时间后能够再次请求服务。 431 Request Header Fields Too Large (请求头字段太大) 某些状况下，客户端发送 HTTP 请求头会变得很大，那么服务器可发送 431 Request Header Fields Too Large 来指明该问题。 我不太清楚为何没有 430 状态码，而是直接从 429 跳到 431，我尝试搜索但没有结果。惟一的猜想是 430 Forbidden 跟 403 Forbidden 太像了，为了不混淆才这么作的，天知道！ 511 Network Authentication Required (要求网络认证) 对我来讲这个状态码颇有趣，若是你在开发一个 HTTP 服务器，你不必定须要处理该状态码，但若是你在编写 HTTP 客户端，那这个状态码就很是重要。 若是你频繁使用笔记本和智能手机，你可能会注意到大量的公用 WIFI 服务要求你必须接受一些协议或者必须登陆后才能使用。 这是经过拦截HTTP流量，当用户试图访问网络返回一个重定向和登陆，这很讨厌，可是实际状况就是这样的。 使用这些“拦截”客户端，会有一些讨厌的反作用。在 RFC 中有提到这两个的例子： 若是你在登陆WIFI前访问某个网站，网络设备将会拦截首个请求，这些设备每每也有本身的网站图标 ‘favicon.ico'。登陆后您会发现，有一段时间内你访问的网站图标一直是WIFI登陆网站的图标。 若是客户端使用HTTP请求来查找文档（多是JSON），网络将会响应一个登陆页，这样你的客户端就会解析错误并致使客户端运行异常，在现实中这种问题很是常见。 所以 511 状态码的提出就是为了解决这个问题。 若是你正在编写 HTTP 的客户端，你最好仍是检查 511 状态码以确认是否须要认证后才能访问。 (责任编辑：admin)

•     您可能对如下的相关文章感兴趣：
•     VC++ HTTP协议之POST方法
•     C语言实现 HTTP 中的chunked解码函数
•     TCP协议状态详解
•     HTTP状态码完整介绍
•     HTTP协议详解
•     http协议状态码解释详细说明
•     合做协议书范本(二)
•     Red Hat Linux 9.0架设FTP服务器