通用头域
请求消息
响应消息
实体信息
消息
|
描述
|
---|---|
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协议版本。
|
2.6 请求头
HTTP最常见的请求头如下:
l Accept:浏览器可接受的MIME类型;
l Accept-Charset:浏览器可接受的字符集;
l Accept-Encoding:浏览器能够进行解码的数据编码方式,比如gzip。Servlet能够向支持gzip的浏览器返回经gzip编码的HTML页面。许多情形下这可以减少5到10倍的下载时间;
l Accept-Language:浏览器所希望的语言种类,当服务器能够提供一种以上的语言版本时要用到;
l Authorization:授权信息,通常出现在对服务器发送的WWW-Authenticate头的应答中;
l Connection:表示是否需要持久连接。如果Servlet看到这里的值为“Keep-Alive”,或者看到请求使用的是HTTP 1.1(HTTP 1.1默认进行持久连接),它就可以利用持久连接的优点,当页面包含多个元素时(例如Applet,图片),显著地减少下载所需要的时间。要实现这一点,Servlet需要在应答中发送一个Content-Length头,最简单的实现方法是:先把内容写入ByteArrayOutputStream,然后在正式写出内容之前计算它的大小;
l Content-Length:表示请求消息正文的长度;
l Cookie:这是最重要的请求头信息之一;
l From:请求发送者的email地址,由一些特殊的Web客户程序使用,浏览器不会用到它;
l Host:初始URL中的主机和端口;
l If-Modified-Since:只有当所请求的内容在指定的日期之后又经过修改才返回它,否则返回304“Not Modified”应答;
l Pragma:指定“no-cache”值表示服务器必须返回一个刷新后的文档,即使它是代理服务器而且已经有了页面的本地拷贝;
l Referer:包含一个URL,用户从该URL代表的页面出发访问当前请求的页面。
l User-Agent:浏览器类型,如果Servlet返回的内容与浏览器类型有关则该值非常有用;
l UA-Pixels,UA-Color,UA-OS,UA-CPU:由某些版本的IE浏览器所发送的非标准的请求头,表示屏幕大小、颜色深度、操作系统和CPU类型。
2.7 响应头
HTTP最常见的响应头如下所示:
l Allow:服务器支持哪些请求方法(如GET、POST等);
l Content-Encoding:文档的编码(Encode)方法。只有在解码之后才可以得到Content-Type头指定的内容类型。利用gzip压缩文档能够显著地减少HTML文档的下载时间。Java的GZIPOutputStream可以很方便地进行gzip压缩,但只有Unix上的Netscape和Windows上的IE 4、IE 5才支持它。因此,Servlet应该通过查看Accept-Encoding头(即request.getHeader("Accept-Encoding"))检查浏览器是否支持gzip,为支持gzip的浏览器返回经gzip压缩的HTML页面,为其他浏览器返回普通页面;
l Content-Length:表示内容长度。只有当浏览器使用持久HTTP连接时才需要这个数据。如果你想要利用持久连接的优势,可以把输出文档写入ByteArrayOutputStram,完成后查看其大小,然后把该值放入Content-Length头,最后通过byteArrayStream.writeTo(response.getOutputStream()发送内容;
l Content-Type: 表示后面的文档属于什么MIME类型。Servlet默认为text/plain,但通常需要显式地指定为text/html。由于经常要设置Content-Type,因此HttpServletResponse提供了一个专用的方法setContentTyep。 可在web.xml文件中配置扩展名和MIME类型的对应关系;
l Date:当前的GMT时间。你可以用setDateHeader来设置这个头以避免转换时间格式的麻烦;
l Expires:指明应该在什么时候认为文档已经过期,从而不再缓存它。
l Last-Modified:文档的最后改动时间。客户可以通过If-Modified-Since请求头提供一个日期,该请求将被视为一个条件GET,只有改动时间迟于指定时间的文档才会返回,否则返回一个304(Not Modified)状态。Last-Modified也可用setDateHeader方法来设置;
l Location:表示客户应当到哪里去提取文档。Location通常不是直接设置的,而是通过HttpServletResponse的sendRedirect方法,该方法同时设置状态代码为302;
l Refresh:表示浏览器应该在多少时间之后刷新文档,以秒计。除了刷新当前文档之外,你还可以通过setHeader("Refresh", "5; URL=http://host/path")让浏览器读取指定的页面。注意这种功能通常是通过设置HTML页面HEAD区的<META HTTP-EQUIV="Refresh" CONTENT="5;URL=http://host/path">实现,这是因为,自动刷新或重定向对于那些不能使用CGI或Servlet的HTML编写者十分重要。但是,对于Servlet来说,直接设置Refresh头更加方便。注意Refresh的意义是“N秒之后刷新本页面或访问指定页面”,而不是“每隔N秒刷新本页面或访问指定页面”。因此,连续刷新要求每次都发送一个Refresh头,而发送204状态代码则可以阻止浏览器继续刷新,不管是使用Refresh头还是<META HTTP-EQUIV="Refresh" ...>。注意Refresh头不属于HTTP 1.1正式规范的一部分,而是一个扩展,但Netscape和IE都支持它。
2.8实体头
实体头用坐实体内容的元信息,描述了实体内容的属性,包括实体信息类型,长度,压缩方法,最后一次修改时间,数据有效性等。
l Allow:GET,POST
l Content-Encoding:文档的编码(Encode)方法,例如:gzip,见“2.5 响应头”;
l Content-Language:内容的语言类型,例如:zh-cn;
l Content-Length:表示内容长度,eg:80,可参考“2.5响应头”;
l Content-Location:表示客户应当到哪里去提取文档,例如:http://www.dfdf.org/dfdf.html,可参考“2.5响应头”;
l Content-MD5:MD5 实体的一种MD5摘要,用作校验和。发送方和接受方都计算MD5摘要,接受方将其计算的值与此头标中传递的值进行比较。Eg1:Content-MD5: <base64 of 128 MD5 digest>。Eg2:dfdfdfdfdfdfdff==;
l Content-Range:随部分实体一同发送;标明被插入字节的低位与高位字节偏移,也标明此实体的总长度。Eg1:Content-Range: 1001-2000/5000,eg2:bytes 2543-4532/7898
l Content-Type:标明发送或者接收的实体的MIME类型。Eg:text/html; charset=GB2312 主类型/子类型;
l Expires:为0证明不缓存;
l Last-Modified:WEB 服务器认为对象的最后修改时间,比如文件的最后修改时间,动态页面的最后产生时间等等。例如:Last-Modified:Tue, 06 May 2008 02:42:43 GMT.
2.8扩展头
在HTTP消息中,也可以使用一些再HTTP1.1正式规范里没有定义的头字段,这些头字段统称为自定义的HTTP头或者扩展头,他们通常被当作是一种实体头处理。
现在流行的浏览器实际上都支持Cookie,Set-Cookie,Refresh和Content-Disposition等几个常用的扩展头字段。
l Refresh:1;url=http://www.dfdf.org //过1秒跳转到指定位置;
l Content-Disposition:头字段,可参考“2.5响应头”;
l Content-Type:WEB 服务器告诉浏览器自己响应的对象的类型。
eg1:Content-Type:application/xml ;
eg2:applicaiton/octet-stream;
Cookie和Session
Cookie和Session都为了用来保存状态信息,都是保存客户端状态的机制,它们都是为了解决HTTP无状态的问题而所做的努力。
Session可以用Cookie来实现,也可以用URL回写的机制来实现。用Cookie来实现的Session可以认为是对Cookie更高级的应用。
3.1.1两者比较
Cookie和Session有以下明显的不同点:
1)Cookie将状态保存在客户端,Session将状态保存在服务器端;
2)Cookies是服务器在本地机器上存储的小段文本并随每一个请求发送至同一个服务器。Cookie最早在RFC2109中实现,后续RFC2965做了增强。网络服务器用HTTP头向客户端发送cookies,在客户终端,浏览器解析这些cookies并将它们保存为一个本地文件,它会自动将同一服务器的任何请求缚上这些cookies。Session并没有在HTTP的协议中定义;
3)Session是针对每一个用户的,变量的值保存在服务器上,用一个sessionID来区分是哪个用户session变量,这个值是通过用户的浏览器在访问的时候返回给服务器,当客户禁用cookie时,这个值也可能设置为由get来返回给服务器;
4)就安全性来说:当你访问一个使用session 的站点,同时在自己机子上建立一个cookie,建议在服务器端的SESSION机制更安全些.因为它不会任意读取客户存储的信息。
3.1.2 Session机制
Session机制是一种服务器端的机制,服务器使用一种类似于散列表的结构(也可能就是使用散列表)来保存信息。
当程序需要为某个客户端的请求创建一个session的时候,服务器首先检查这个客户端的请求里是否已包含了一个session标识 - 称为 session id,如果已包含一个session id则说明以前已经为此客户端创建过session,服务器就按照session id把这个 session检索出来使用(如果检索不到,可能会新建一个),如果客户端请求不包含session id,则为此客户端创建一个session并且生成一个与此session相关联的session id,session id的值应该是一个既不会重复,又不容易被找到规律以仿造的字符串,这个 session id将被在本次响应中返回给客户端保存。
3.1.6 Session的实现方式
3.1.6.1 使用Cookie来实现
服务器给每个Session分配一个唯一的JSESSIONID,并通过Cookie发送给客户端。
当客户端发起新的请求的时候,将在Cookie头中携带这个JSESSIONID。这样服务器能够找到这个客户端对应的Session。
流程如下图所示:
3.1.6.2 使用URL回显来实现
URL回写是指服务器在发送给浏览器页面的所有链接中都携带JSESSIONID的参数,这样客户端点击任何一个链接都会把JSESSIONID带会服务器。
如果直接在浏览器输入服务端资源的url来请求该资源,那么Session是匹配不到的。
Tomcat对Session的实现,是一开始同时使用Cookie和URL回写机制,如果发现客户端支持Cookie,就继续使用Cookie,停止使用URL回写。如果发现Cookie被禁用,就一直使用URL回写。jsp开发处理到Session的时候,对页面中的链接记得使用response.encodeURL() 。
3.1.3在J2EE项目中Session失效的几种情况
1)Session超时:Session在指定时间内失效,例如30分钟,若在30分钟内没有操作,则Session会失效,例如在web.xml中进行了如下设置:
<session-config>
<session-timeout>30</session-timeout> //单位:分钟
</session-config>
2)使用session.invalidate()明确的去掉Session。
3.1.4与Cookie相关的HTTP扩展头
1)Cookie:客户端将服务器设置的Cookie返回到服务器;
2)Set-Cookie:服务器向客户端设置Cookie;
3)Cookie2 (RFC2965)):客户端指示服务器支持Cookie的版本;
4)Set-Cookie2 (RFC2965):服务器向客户端设置Cookie。
Cookie的流程
服务器在响应消息中用Set-Cookie头将Cookie的内容回送给客户端,客户端在新的请求中将相同的内容携带在Cookie头中发送给服务器。从而实现会话的保持。
GET和POST
常用的请求方式是GET和POST.
l GET方式:是以实体的方式得到由请求URI所指定资源的信息,如果请求URI只是一个数据产生过程,那么最终要在响应实体中返回的是处理过程的结果所指向的资源,而不是处理过程的描述。
l POST方式:用来向目的服务器发出请求,要求它接受被附在请求后的实体,并把它当作请求队列中请求URI所指定资源的附加新子项,Post被设计成用统一的方法实现下列功能:
1:对现有资源的解释;
2:向电子公告栏、新闻组、邮件列表或类似讨论组发信息;
3:提交数据块;
4:通过附加操作来扩展数据库 。
从上面描述可以看出,Get是向服务器发索取数据的一种请求;而Post是向服务器提交数据的一种请求,要提交的数据位于信息头后面的实体中。
GET与POST方法有以下区别:
(1) 在客户端,Get方式在通过URL提交数据,数据在URL中可以看到,请求的数据会附在URL之后(就是把数据放置在HTTP协议头中),以?分割URL和传输数据,多个参数用&连接。如果数据是英文字母/数字,原样发送,如果是空格,转换为+,如果是中文/其他字符,则直接把字符串用BASE64加密,得出如: %E4%BD%A0%E5%A5%BD,其中%XX中的XX为该符号以16进制表示的ASCII。;POST方式,数据放置在HTML HEADER内提交。
(2) GET方式提交的数据最多只能有1024字节,而POST则没有此限制。
而在实际开发中存在的限制主要有:
GET:特定浏览器和服务器对URL长度有限制,例如IE对URL长度的限制是2083字节(2K+35)。对于其他浏览器,如Netscape、FireFox等,理论上没有长度限制,其限制取决于操作系统的支持。
因此对于GET提交时,传输数据就会受到URL长度的限制。
POST:由于不是通过URL传值,理论上数据不受限。但实际各个WEB服务器会规定对post提交数据大小进行限制,Apache、IIS6都有各自的配置。
(3) 安全性问题。正如在(1)中提到,使用 Get 的时候,参数会显示在地址栏上,而 Post 不会。所以,如果这些数据是中文数据而且是非敏感数据,那么使用 get;如果用户输入的数据不是中文字符而且包含敏感数据,那么还是使用 post为好。
(4) 安全的和幂等的。所谓安全的意味着该操作用于获取信息而非修改信息。幂等的意味着对同一 URL 的多个请求应该返回同样的结果。完整的定义并不像看起来那样严格。换句话说,GET 请求一般不应产生副作用。从根本上讲,其目标是当用户打开一个链接时,她可以确信从自身的角度来看没有改变资源。比如,新闻站点的头版不断更新。虽然第二次请求会返回不同的一批新闻,该操作仍然被认为是安全的和幂等的,因为它总是返回当前的新闻。反之亦然。POST 请求就不那么轻松了。POST 表示可能改变服务器上的资源的请求。仍然以新闻站点为例,读者对文章的注解应该通过 POST 请求实现,因为在注解提交之后站点已经不同了。
HTTP 定义了与服务器交互的不同方法,最常用的有4种,Put(增),Delete(删),Post(改),Get(查),即增删改查:
1)Get, 它用于获取信息,注意,他只是获取、查询数据,也就是说它不会修改服务器上的数据,从这点来讲,它是数据安全的,而稍后会提到的Post它是可以修改数据的,所以这也是两者差别之一了。
2) Post,它是可以向服务器发送修改请求,从而修改服务器的,比方说,我们要在论坛上回贴、在博客上评论,这就要用到Post了,当然它也是可以仅仅获取数据的。
3)Delete 删除数据。可以通过Get/Post来实现。
4)Put,增加、放置数据,可以通过Get/Post来实现。
根据HTTP规范,GET用于信息获取,而且应该是安全的和幂等的 。
1.所谓安全的意味着该操作用于获取信息而非修改信息。换句话说,GET请求一般不应产生副作用。就是说,仅仅是获取资源信息,就像数据库查询一样,不会修改,增加数据,不会影响资源的状态。(注意:这里安全的含义仅仅是指是非修改信息。)
根据HTTP规范,POST表示可能修改变服务器上的资源的请求 。继续引用上面的例子:还是新闻以网站为例,读者对新闻发表自己的评论应该通过POST实现,因为在评论提交后站点的资源已经不同了,或者说资源被修改了。
表现形式区别:
HTTP请求:在HTTP请求中,第一行必须是一个请求行(request line),用来说明请求类型、要访问的资源以及使用的HTTP版本。紧接着是一个首部(header)小节,用来说明服务器要使用的附加信息。在首部之后是一个空行,再此之后可以添加任意的其他数据[称之为主体(body)]。