《HTTP请求与响应》由会员分享，可在线阅读，更多相关《HTTP请求与响应（7页珍藏版）》请在金锄头文库上搜索。
1、 恳求与响应 恳求由三局部组成，分别是：恳求行、消息报头、恳求正文恳求行以一个方法符号开头，以空格分开，后面跟着恳求的URI 和协议的版本，格式如下：Method Request-URI -Version CRLF其中 Method 表示恳求方法；Request-URI 是一个统一资源标识符； -Version 表示恳求的 协议版本；CRLF 表示回车和换行除了作为结尾的CRLF 外，不允许消灭单独的CR 或 LF 字符。恳求方法全部方法全为大写有多种，各个方法的解释如下：GET恳求猎取Request-URI 所标识的资源POST在 Request-URI 所标识的资源后附加新的数据HEAD
2、恳求猎取由Request-URI 所标识的资源的响应消息报头PUT 恳求效劳器存储一个资源，并用Request-URI 作为其标识DELETE 恳求效劳器删除Request-URI 所标识的资源TRACE恳求效劳器回送收到的恳求信息，主要用于测试或诊断CONNECT 保存将来使用OPTIONS 恳求查询效劳器的性能，或者查询与资源相关的选项和需求一 恳求1 恳求格式： 在 恳求中，第一行必需是一个恳求行request line，用来说明恳求类型、要访问的资源以及使用的 版本。紧接着是一个首部header小节，用来说明效劳器要使用的附加信息。在首部之后是一个空行，再此之后可以添加任意的其他数据称
3、之为主体body。 2GET 与POST 区分 定义了与效劳器交互的不同方法如上所示，最根本的方法是 GET 和 POST。GET 与POST 方法有以下区分：（1） 在客户端，Get 方式在通过URL 提交数据，数据在URL 中可以看到；POST 方式，数据放置在HTML HEADER 内提交。（2） GET 方式提交的数据最多只能有 1024 字节，而POST 那么没有此限制。（3） 平安性问题。正如在1中提到，使用 Get 的时候，参数会显示在地址栏上，而Post不会。所以，假设这些数据是中文数据而且是非敏感数据，那么使用get；假设用户输 入的数据不是中文字符而且包含敏感数据，那么还是
4、使用 post 为好。（4） 平安的和幂等的。所谓平安的意味着该操作用于猎取信息而非修改信息。幂等的意味 着对同一 URL 的多个恳求应当返回同样的结果。完整的定义并不像看起来那样严格。换句话说，GET 恳求一般不应产生副作用。从根本上讲，其目标是当用户翻开一个链接时，她可以确信从自身的角度来看没有转变资源。比方，新闻站点的头版不断更新。虽然其次次请 求会返回不同的一批新闻，该操作仍旧被认为是平安的和幂等的，由于它总是返回当前的新 闻。反之亦然。POST 恳求就不那么轻松了。POST 表示可能转变效劳器上的资源的恳求。仍旧以新闻站点为例，读者对文章的注解应当通过 POST 恳求实现，由于在注解
5、提交之后站点已经不同了。GET 与POST 方法实例：GET 实例GET /books/?name=windows 内核平安编程 /1.1 Host: wrox User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)Connection: Keep-AlivePOST 实例POST / /1.1Host: wrox User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Content-Type: application/x-w
6、ww-form-urlencodedContent-Length: 40 Connection: Keep-Alive/此处空一行name=windows 编程&Writer=tanwen二 响应1 响应格式： 在响应中唯一真正的区分在于第一行中用状态信息代替了恳求信息。状态行status line通过供给一个状态码来说明所恳求的资源状况。典型的响应消息： /1.1 200 0KConnection : closeDate: Thu, 13 Oct 2005 03:17:33 GMTServer: Apache/2.0.54 (Unix) LastModified:Mon,22 Jun 199
7、8 09;23;24 GMT ContentLength:682lContentType :text/html(数据 数据 数据 数据 数据)这个响应消息分为 3 局部：1 个起始的状态行(status line)，6 个头部行、1 个包含所恳求对象本身的附属体。状态行有 3 个字段:协议版本字段、状态码字段、缘由短语字段。本例的状态行说明，效劳器使用 /1.1 版本，响应过程完全正常(也就是说效劳器找到了所恳求的对象，并正在发送)。现在看一下本例中的各个头部行。效劳器使用 Connection: close 头部行告知客户自己将在发送完本消息后关闭TCP 连接。Date:头部行指出效劳器创立
8、并发送本响应消息的日期和2最常用的状态码有：时间。留意，这并不是对象本身的创立时间或最终修改时间，而是效劳器把该对象从其文件系统中取出，插入响应消息中发送出去的时间。Server:头部行指出本消息是由 Apache 效劳器产生的;它与 恳求消息中的User-agent:头部行类似。LastModified:头部行指出对象本身的创立或最终修改日期或时间。LastModified 头部对于对象的高速缓存至关重要，且不管这种高速缓存是发生在本地客户主机上还是发生在网络高速缓存效劳器主机(也就是代 理效劳器主机)上。ContentLength:头部行指出所发送对象的字节数。ContentType:头部
9、 行指出包含在附属体中的对象是HTML 文本。对象的类型是由ContentType 头部而不是由文件扩展名正式指出的。 200 (OK): 找到了该资源，并且一切正常。 304 (NOT MODIFIED): 该资源在上次恳求之后没有任何修改。这通常用于扫瞄器的缓存机制。 401 (UNAUTHORIZED): 客户端无权访问该资源。这通常会使得扫瞄器要求用户输入用户名和密码，以登录到效劳器。 403 (FORBIDDEN): 客户端未能获得授权。这通常是在 401 之后输入了不正确的用户名或密码。 404 (NOT FOUND): 在指定的位置不存在所申请的资源。1xx: 信息响应类，表示接
10、收到恳求并且连续处理2xx: 处理成功响应类，表示动作被成功接收、理解和承受3xx: 重定向响应类，为了完成指定的动作，必需承受进一步处理4xx: 客户端错误，客户恳求包含语法错误或者是不能正确执行5xx: 效劳端错误，效劳器不能正确执行一个正确的恳求500 Internal Server Error 恳求未完成。效劳器遇到不行预知的状况。5xx:效劳器错误消息: 描述:501 Not Implemented 恳求未完成。效劳器不支持所恳求的功能。502 Bad Gateway 恳求未完成。效劳器从上游效劳器收到一个无效的响应。503 Service Unavailable 恳求未完成。效劳器
11、临时过载或当机。504 Gateway Timeout 网关超时。505 Version Not Supported 效劳器不支持恳求中指明的 协议版本。消息报头的分类： 消息由客户端到效劳器的恳求和效劳器到客户端的响应组成。恳求消息和响应消息都是由开头行对于恳求消息，开头行就是恳求行，对于响应消息，开头行就是状态行，消息报头可选，空行只有 CRLF 的行，消息正文可选组成。 消息报头包括一般报头、恳求报头、响应报头、实体报头。每一个报头域都是由名字+“：”+空格+值 组成，消息报头域的名字是大小写无关的。1、一般报头在一般报头中，有少数报头域用于全部的恳求和响应消息，但并不用于被传输的实体，
12、只用于传输的消息。eg：Cache-Control 用于指定缓存指令，缓存指令是单向的响应中消灭的缓存指令在恳求中未必会消灭，且是独立的一个消息的缓存指令不会影响另一个消息处理的缓存机制， 1.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-ag
13、e、s-maxage.eg ： 为了指示 IE 扫瞄器 客户端 不要缓存页面， 效劳器端的 JSP 程序可以编写如下：response.sehHeader(“Cache-Control“,“no-cache“);/response.setHeader(“Pragma“,“no-cache“);作用相当于上述代码，通常两者/合用这句代码将在发送的响应消息中设置一般报头域：Cache-Control:no-cacheDate 一般报头域表示消息产生的日期和时间Connection 一般报头域允许发送指定连接的选项。例如指定连接是连续，或者指定“clos选e”项，通知效劳器，在响应完成后，关闭连接2
14、、恳求报头恳求报头允许客户端向效劳器端传递恳求的附加信息以及客户端自身的信息。常用的恳求报头AcceptAccept 恳求报头域用于指定客户端承受哪些类型的信息。eg：Accept：image/gif，说明客户端期望承受GIF图象格式的资源；Accept：text/html，说明客户端期望承受 html 文本。Accept-CharsetAccept-Charset 恳求报头域用于指定客户端承受的字符集。eg：Accept-Charset:iso-8859-1,gb2312.假设在恳求消息中没有设置这个域，缺省是任何字符集都可以承受。Accept-EncodingAccept-Encoding请 求 报 头 域 类 似 于 Accept ， 但 是 它 是 用 于 指 定 可 接 受 的 内 容 编 码 。 eg ： Accept-Encoding:gzip.deflate.假设恳求消息中没有设置这个域效劳器假定客户端对各种内容编码都可以承受。Accept-LanguageAccept-Language 恳求报头域类似于 Accept，但是它是用于指定一种自然语言。eg：Accept-Language:zh-cn.假设恳求消息中没有设置这个报头域，效劳器假定客户端对各种语言都可以承受。AuthorizationAuthorizatio
