HTTP请求响应方式总结
HTTP请求方式
以下内容综合整理来自如下列连接的资料：
http://www.cnblogs.com/Josh-or-Tom/archive/2012/07/17/2595657.html
http://blog.csdn.net/core_star/article/details/4881057
http://www.douban.com/note/180488791/
当浏览器向Web服务器发出请求时，它向服务器传递了一个数据块，也就是请求信息，HTTP请求信息由3部分组成：
1).请求方法URI协议/版本
2).请求头(Request Header)
3).请求正文
下面是一个HTTP请求的例子：
// 请求方法uri, 协议、版本
GET/sample.jsp HTTP/1.1
// 请求头
Accept:image/gif.image/jpeg,*/*
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)
Accept-Encoding:gzip,deflate
// 请求正文
username=jinqiao&password=1234
（1）请求方法URI协议/版本
请求的第一行是“方法URL议/版本”：GET/sample.jsp HTTP/1.1
以上代码中“GET”代表请求方法，“/sample.jsp”表示URI，“HTTP/1.1代表协议和协议的版本。
根据HTTP标准，HTTP请求可以使用多种请求方法。例如：HTTP1.1目前支持7种请求方法：GET、POST、HEAD、OPTIONS、PUT、DELETE和TARCE。
GET 请求获取由Request-URI所标识的资源。
POST 在Request-URI所标识的资源后附加新的数据，给服务器提交数据。
HEAD 请求获取由Request-URI所标识的资源的响应消息报头。
OPTIONS 请求查询服务器的性能，或查询与资源相关的选项和需求。
PUT 请求服务器存储一个资源，并用Request-URI作为其标识。
DELETE 请求服务器删除由Request-URI所标识的资源。
TRACE 请求服务器回送收到的请求信息，主要用语测试或诊断。
在Internet应用中，最常用的方法是GET和POST。
URI完整地指定了要访问的网络资源，通常只要给出相对于服务器的根目录的相对目录即可，因此总是以“/”开头，最后，协议版本声明了通信过程中使用HTTP的版本。
（2）请求头(Request Header)
请求头包含许多有关的客户端环境和请求正文的有用信息。例如，请求头可以声明浏览器所用的语言，请求正文的长度等。
Accept:image/gif.image/jpeg.*/*
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible:MSIE5.01:Windows NT5.0)
Accept-Encoding:gzip,deflate.
（3）请求正文
请求头和请求正文之间是一个空行，这个行非常重要，它表示请求头已经结束，接下来的是请求正文。请求正文中可以包含客户提交的查询字符串信息：
username=jinqiao&password=1234
在以上的例子的HTTP请求中，请求的正文只有一行内容。当然，在实际应用中，HTTP请求正文可以包含更多的内容。
HTTP请求方法我这里只讨论GET方法与POST方法
GET方法
GET方法是默认的HTTP请求方法，我们日常用GET方法来提交表单数据，然而用GET方法提交的表单数据只经过了简单的编码，同时它将作为URL的一部分向Web服务器发送，因此，如果使用GET方法来提交表单数据就存在着安全隐患上。例如
Http://127.0.0.1/login.jsp?Name=zhangshi&Age=30&Submit=%cc%E+%BD%BB
从上面的URL请求中，很容易就可以辩认出表单提交的内容。（？之后的内容）另外由于GET方法提交的数据是作为URL请求的一部分所以提交的数据量不能太大
POST方法
POST方法是GET方法的一个替代方法，它主要是向Web服务器提交表单数据，尤其是大批量的数据。POST方法克服了GET方法的一些缺点。通过POST方法提交表单数据时，数据不是作为URL请求的一部分而是作为标准数据传送给Web服务器，这就克服了GET方法中的信息无法保密和数据量太小的缺点。因此，出于安全的考虑以及对用户隐私的尊重，通常表单提交时采用POST方法。
从编程的角度来讲，如果用户通过GET方法提交数据，则数据存放在QUERY＿STRING环境变量中，而POST方法提交的数据则可以从标准输入流中获取。
HTTP应答与HTTP请求相似，HTTP响应也由3个部分构成，分别是：
1 状态行
2 响应头(Response Header)
3 响应正文
在接收和解释请求消息后，服务器会返回一个HTTP响应消息。
状态行由协议版本、数字形式的状态代码、及相应的状态描述，各元素之间以空格分隔。
格式: HTTP-Version Status-Code Reason-Phrase CRLF
例如: HTTP/1.1 200 OK \r\n
状态代码由3位数字组成，表示请求是否被理解或被满足。
状态描述：
状态描述给出了关于状态代码的简短的文字描述。
状态代码的第一个数字定义了响应的类别，后面两位没有具体的分类。
第一个数字有五种可能的取值：
- 1xx: 指示信息—表示请求已接收，继续处理。
- 2xx: 成功—表示请求已经被成功接收、理解、接受。
- 3xx: 重定向—要完成请求必须进行更进一步的操作。
- 4xx: 客户端错误—请求有语法错误或请求无法实现。
- 5xx:服务器端错误—服务器未能实现合法的请求。
状态代码状态描述 说明
200 OK 客户端请求成功
400 Bad Request 由于客户端请求有语法错误，不能被服务器所理解。
401 Unauthonzed 请求未经授权。这个状态代码必须和WWW-Authenticate报头域一起使用
403 Forbidden 服务器收到请求，但是拒绝提供服务。服务器通常会在响应正文中给出不提供服务的原因
404 Not Found 请求的资源不存在，例如，输入了错误的URL。
500 Internal Server Error 服务器发生不可预期的错误，导致无法完成客户端的请求。
503 Service Unavailable 服务器当前不能够处理客户端的请求，在一段时间之后，服务器可能会恢复正常。
响应头
响应头可能包括：
Location：
Location响应报头域用于重定向接受者到一个新的位置。例如：客户端所请求的页面已不存在原先的位置，为了让客户端重定向到这个页面新的位置，服务器端可以发回Location响应报头后使用重定向语句，让客户端去访问新的域名所对应的服务器上的资源。当我们在JSP中使用重定向语句的时候，服务器端向客户端发回的响应报头中，就会有Location响应报头域。
Server：
Server响应报头域包含了服务器用来处理请求的软件信息。它和User-Agent请求报头域是相对应的，前者发送服务器端软件的信息，后者发送客户端软件(浏览器)和操作系统的信息。下面是Server响应报头域的一个例子：Server: Apache-Coyote/1.1
WWW-Authenticate：
WWW-Authenticate响应报头域必须被包含在401(未授权的)响应消息中，这个报头域和前面讲到的Authorization请求报头域是相关的，当客户端收到401响应消息，就要决定是否请求服务器对其进行验证。如果要求服务器对其进行验证，就可以发送一个包含了 Authorization报头域的请求，下面是WWW-Authenticate响应报头域的一个例子：WWW-Authenticate: Basic realm="Basic Auth Test!"
从这个响应报头域，可以知道服务器端对我们所请求的资源采用的是基本验证机制。
Content-Encoding：
Content-Encoding实体报头域被使用作媒体类型的修饰符，它的值指示了已经被应用到实体正文的附加内容编码，因而要获得Content- Type报头域中所引用的媒体类型，必须采用相应的解码机制。Content-Encoding主要用语记录文档的压缩方法，下面是它的一个例子： Content-Encoding: gzip。如果一个实体正文采用了编码方式存储，在使用之前就必须进行解码。
Content-Language：
Content-Language实体报头域描述了资源所用的自然语言。Content-Language允许用户遵照自身的首选语言来识别和区分实体。如果这个实体内容仅仅打算提供给丹麦的阅读者，那么可以按照如下的方式设置这个实体报头域：Content-Language: da。
如果没有指定Content-Language报头域，那么实体内容将提供给所以语言的阅读者。
Content-Length：
Content-Length实体报头域用于指明正文的长度，以字节方式存储的十进制数字来表示，也就是一个数字字符占一个字节，用其对应的ASCII码存储传输。
要注意的是：这个长度仅仅是表示实体正文的长度，没有包括实体报头的长度。
Content-Type
Content-Type实体报头域用语指明发送给接收者的实体正文的媒体类型。例如：
Content-Type: text/html;charset=ISO-8859-1
Content-Type: text/html;charset=GB2312
Last-Modified
Last-Modified实体报头域用于指示资源最后的修改日期及时间。
Expires
Expires实体报头域给出响应过期的日期和时间。通常，代理服务器或浏览器会缓存一些页面。当用户再次访问这些页面时，直接从缓存中加载并显示给用户，这样缩短了响应的时间，减少服务器的负载。为了让代理服务器或浏览器在一段时间后更新页面，我们可以使用Expires实体报头域指定页面过期的时间。当用户又一次访问页面时，如果Expires报头域给出的日期和时间比Date普通报头域给出的日期和时间要早(或相同)，那么代理服务器或浏览器就不会再使用缓存的页面而是从服务器上请求更新的页面。不过要注意，即使页面过期了，也并不意味着服务器上的原始资源在此时间之前或之后发生了改变。
Expires实体报头域使用的日期和时间必须是RFC 1123中的日期格式，例如：
Expires: Thu, 15 Sep 2005 16:00:00 GMT
HTTP1.1的客户端和缓存必须将其他非法的日期格式(也包括0)看作已过期。例如，为了让浏览器不要缓存页面，我们也可以利用Expires实体报头域，设置它的值为0，如下(JSP)：response.setDateHeader("Expires",0);
下面是一个HTTP响应的例子：
HTTP/1.1 200 OK
Server:Apache Tomcat/5.0.12
Date:Mon,6Oct2003 13:23:42 GMT
Content-Length:112
Http方法：Get请求与Post请求的区别
Get是向服务器发索取数据的一种请求，而Post是向服务器提交数据的一种请求
Get是获取信息，而不是修改信息，类似数据库查询功能一样，数据不会被修改
Get请求的参数会跟在url后进行传递，请求的数据会附在URL之后，以?分割URL和传输数据，参数之间以&相连,％XX中的XX为该符号以16进制表示的ASCII，如果数据是英文字母/数字，原样发送，如果是空格，转换为+，如果是中文/其他字符，则直接把字符串用BASE64加密。
Get传输的数据有大小限制，因为GET是通过URL提交数据，那么GET可提交的数据量就跟URL的长度有直接关系了，不同的浏览器对URL的长度的限制是不同的。
GET请求的数据会被浏览器缓存起来，用户名和密码将明文出现在URL上，其他人可以查到历史浏览记录，数据不太安全。在服务器端，用Request.QueryString来获取Get方式提交来的数据
Post请求则作为http消息的实际内容发送给web服务器，数据放置在HTML Header内提交，Post没有限制提交的数据。Post比Get安全，当数据是中文或者不敏感的数据，则用get，因为使用get，参数会显示在地址，对于敏感数据和不是中文字符的数据，则用post
POST表示可能修改变服务器上的资源的请求，在服务器端，用Post方式提交的数据只能用Request.Form来获取
GET
GET方法意思是获取被请求URI（Request-URI）指定的信息（以实体的格式）。如果请求
URI涉及到一个数据生成过程，那么这个过程生成的数据应该被作为实体在响应中返回而不是
过程的源文本，除非源文本恰好是过程的输出。
如果请求消息包含 If-Modified-Since,，If-Unmodified-Since，If-Match，If-None-Match 或者
If-Range头域，GET的语义将变成“条件（conditionall） GET”。一个条件GET方法会请求满
足条件头域的实体。条件GET方法的目的是为了减少不必要的网络使用，这通过允许利用缓存
里仍然保鲜的实体而不用多次请求或传输客户端已经拥有的实体来实现的。.
如果请求方法包含一个Range头域，那么GET方法就变成“部分Get”（partial GET）方法。
一个部分GET会请求实体的一部分，这在14.35节里描述了。 部分GET方法的目的是为了减
少不必要的网络使用，可以允许客户端从服务器获取实体的部分数据，而不需要获取客户端本
地已经拥有的部分实体数据。
GET请求的响应是可缓存的（cacheable）如果此响应满足第13节HTTP缓存的要求。
看15.1.3节关于GET请求用于表单时安全考虑。
HEAD
HEAD 方法和GET 方法一致，除了服务器不能在响应里返回消息主体。HEAD请求响应里
HTTP头域里的元信息（译注：元信息就是头域信息）应该和GET请求响应里的元信息一致。
此方法被用来获取请求实体的元信息而不需要传输实体主体（entity-body）。此方法经常被用
来测试超文本链接的有效性，可访问性，和最近的改变。.
HEAD请求的响应是可缓存的，因为响应里的信息可能被缓存用于更新以前那个资源对应缓存
的实体.。如果出现一个新的域值指明缓存的实体和当前源服务器上的实体有所不同（可能因为
Content-Length，Content-MD5，ETag或Last-Modified值的改变），那么缓存（cache）必
须认为缓存项是过时的（stale）。
POST
POST 方法被用于请求源服务器接受请求中的实体作为请求资源的一个新的从属物。POST被
设计涵盖下面的功能。
--已存在的资源的注释；
--发布消息给一个布告板，新闻组，邮件列表，或者相似的文章组。
--提供一个数据块，如提交一个表单给一个数据处理过程。
--通过追加操作来扩展数据库。
POST方法的实际功能是由服务器决定的，并且经常依赖于请求URI（Request-URI）。POST
提交的实体是请求URI的从属物，就好像一个文件从属于一个目录，一篇新闻文章从属于一个
新闻组，或者一条记录从属于一个数据库。
POST方法执行的动作可能不会对请求URI所指的资源起作用。在这种情况下，200（成功）或
者204（没有内容）将是适合的响应状态，这依赖于响应是否包含一个描述结果的实体。
如果资源被源服务器创建，响应应该是201（Created）并且包含一个实体，此实体描述了请
求的状态。并且引用了这个新资源和一个Location头域（见14.30节）。
POST方法的响应是不可缓存的。除非响应里有合适的Cache-Control或者Expires头域。然而，
303（见其他）响应能被用户代理利用去获得可缓存的响应。
POST 请求必须遵循8.2节里指明的消息传送的要求。
参见15.1.3节关于安全性的考虑.
PUT
PUT方法请求服务器去把请求里的实体存储在请求URI（Request-URI）标识下。如果请求
URI（Request-URI）指定的的资源已经在源服务器上存在，那么此请求里的实体应该被当作
是源服务器关于此URI所指定资源实体的最新修改版本。如果请求URI（Request-URI）指定
的资源不存在，并且此URI被用户代理定义为一个新资源，那么源服务器就应该根据请求里的
实体创建一个此URI所标识下的资源。如果一个新的资源被创建了，源服务器必须能向用户代
理（user agent） 发送201（已创建）响应。如果已存在的资源被改变了，那么源服务器应该
发送200（Ok）或者204（无内容）响应。如果资源不能根据请求URI创建或者改变，一个合
适的错误响应应该给出以反应问题的性质。实体的接收者不能忽略任何它不理解和不能实现的
Content-*（如：Content-Range）头域，并且必须返回501（没有被实现）响应。
如果请求穿过一个缓存（cache），并且此请求URI（Request-URI）指示了一个或多个当前
缓存的实体，那么这些实体应该被看作是旧的。PUT方法的响应是不可缓存的。
POST方法和PUT方法请求最根本的区别是请求URI（Request-URI）的含义不同。POST请
求里的URI 指示一个能处理请求实体的资源（译注：此资源可能是一段程序，如jsp 里的
servlet） 。此资源可能是一个数据接收过程，一个网关（gateway，译注：网关和代理的区别
是：网关可以进行协议转换，而代理不能，只是起代理的作用，比如缓存服务器其实就是一个
代理），或者一个单独接收注释的实体。对比而言，PUT方法请求里的URI标识请求里封装的
实体一一用户代理知道URI 意指什么，并且服务器不能把此请求应用于其它资源
（resource）。如果服务器期望请求被应用于一个不同的URI，那么它必须发送301（永久移
动）响应；用户代理可以自己决定是否重定向请求。
一个单独的资源可能会被许多不同的URI指定。如：一篇文章可能会有一个URI指定当前版本，
而这个URI区别于这篇文章其它特殊版本的URI。这种情况下，对一个通用URI的PUT请求可
能会导致其资源的其它URI请求被源服务器重定义。
HTTP/1.1没有定义PUT方法对源服务器的状态影响。
PUT请求必须遵循8.2节中的消息传送的要求。
除非特别指出，PUT方法请求里的实体头域应该被用于资源的创建或修改。
DELETE（删除）
DELETE方法请求源服务器删除请求URI指定的资源。此方法可能会在源服务器上被人为的干
涉（或通过其他方法）。客户端不能保证此操作能被执行，即使源服务器返回成功状态码。然而，
服务器不应该指明成功除非它打算删除资源或把此资源移到一个不可访问的位置。
如果响应里包含描述成功的实体，响应应该是200（OK）；如果DELETE动作还没有执行，
应该以202（已接受）响应；如果DELETE请求方法已经执行但响应不包含实体，那么应该以
204（无内容）响应。
如果请求穿过缓存，并且请求URI（Request-URI）指定了一个或多个缓存当前实体，那么这
些缓存项应该被认为是旧的。DELETE方法的响应是不能被缓存的。
TRACE
TRACE方法被用于激发一个远程的，应用层的请求消息回路（译注：TRACE方法让客户端测
试到服务器的网络通路，回路的意思如发送一个请返回一个响应，这就是一个请求响应回路，）。
最后的接收者也许是源服务器，也许是接收到包含Max-Forwards头域值为0请求的代理
或网关。TRACE请求不能包含一个实体。
TRACE方法允许客户端去了解数据被请求链的另一端接收的情况，并且利用那些数据信息去
测试或诊断。Via头域值（见14.45）有特殊的用途，因为它可以作为请求链的跟踪信息。利用
Max-Forwards头域允许客户端限制请求链的长度，这是非常有用的，因为可以利用此去测试代
理链在无限循环里转发消息。
如果请求是有效的，响应应该在实体主体里包含整个请求消息，并且响应应该包含一个
Content-Type头域值为”message/http”的头域。此方法的响应不能被缓存。
CONNECT（连接）
HTTP1.1 协议规范保留了CONNECT方法，此方法是为了能用于能动态切换到隧道的代理
