web性能测试中有一个web资源分析，web资源是从服务器入手对web服务器的性能进行分析。所以了解一下以下信息是很有必要的哦。
 
 一：响应头信息
 
 HTTP（HyperTextTransferProtocol）是超文本传输协议的缩写，它用于传送WWW方式的数据，关于HTTP协议的详 细内容请参考RFC2616。HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求，请求头包含请求的方法、URI、协议版本、以及包含请求修 饰符、客户信息和内容的类似于MIME的消息结构。服务器以一个状态行作为响应，相应的内容包括消息协议的版本，成功或者错误编码加上包含服务器信息、实 体元信息以及可能的实体内容。
 
 通常HTTP消息包括客户机向服务器的请求消息和服务器向客户机的响应消息。这两种类型的消息由一个起始行，一个或者多个头域，一个只是头域结束的空行和可选的消息体组成。HTTP的头域包括通用头，请求头，响应头和实体头四个部分。每个头域由一个域名，冒号（:）和域值三部分组成。域名是大小写无关的，域值前可以添加任何数量的空格符，头域可以被扩展为多行，在每行开始处，使用至少一个空格或制表符。
 
 通用头域 
 
 通用头域包含请求和响应消息都支持的头域，通用头域包含Cache-Control、 Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via。对通用头域的扩展要求通讯双方都支持此扩展，如果存在不支持的通用头域，一般将会作为实体头域处理。下面简单介绍几个在UPnP消息中使用的通用头域。
 
 
 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消息的值，那么客户机可以接收超出超时期指定值之内的响应消息。 
 
 
 Date头域 
 
 Date头域表示消息发送的时间，时间的描述格式由rfc822定义。例如，Date:Mon,31Dec200104:25:57GMT。Date描述的时间表示世界标准时，换算成本地时间，需要知道用户所在的时区。
 
 
 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。对请求头域的扩展要求通讯双方都支持，如果存在不支持的请求头域，一般将会作为实体头域处理。
 
 典型的请求消息： 
 
 GET http://download.microtool.de:80/somedata.exe 
 Host: download.microtool.de 
 Accept:*/* 
 Pragma: no-cache 
 Cache-Control: no-cache 
 Referer: http://download.microtool.de/ 
 User-Agent:Mozilla/4.04[en](Win95;I;Nav) 
 Range:bytes=554554- 
 
 上例第一行表示HTTP客户端（可能是浏览器、下载程序）通过GET方法获得指定URL下的文件。棕色的部分表示请求头域的信息，绿色的部分表示通用头部分。 
 
 
 Host头域 
 
 Host头域指定请求资源的Intenet主机和端口号，必须表示请求url的原始服务器或网关的位置。HTTP/1.1请求必须包含主机头域，否则系统会以400状态码返回。
 
 
 Referer头域 
 
 Referer 头域允许客户端指定请求uri的源资源地址，这可以允许服务器生成回退链表，可用来登陆、优化cache等。他也允许废除的或错误的连接由于维护的目的被追踪。如果请求的uri没有自己的uri地址，Referer不能被发送。如果指定的是部分uri地址，则此地址应该是一个相对地址。
 
 
 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）。 
 
 
 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:bytes554554-40279979/40279980 
 
 上例第一行表示HTTP服务端响应一个GET方法。棕色的部分表示响应头域的信息，绿色的部分表示通用头部分，红色的部分表示实体头域的信息。 
 
 Location响应头 
 
 Location响应头用于重定向接收者到一个新URI地址。 
 
 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定义。
 
 Content-Type实体头 
 
 Content-Type实体头用于向接收方指示实体的介质类型，指定HEAD方法送到接收方的实体介质类型，或GET方法发送的请求介质类型 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表示实际传送的字节数。
 
 Last-modified实体头 
 
 Last-modified实体头指定服务器上保存内容的最后修订时间。 
 
 
 
  
 
应答头
说明
Allow
服务器支持哪些请求方法（如GET、POST等）。
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页面，为其他浏览器返回普通页面。
Content-Length
表示内容长度。只有当浏览器使用持久HTTP连接时才需要这个数据。如果你想要利用持久连接的优势，可以把输出文档写入 ByteArrayOutputStram，完成后查看其大小，然后把该值放入Content-Length头，最后通过 byteArrayStream.writeTo(response.getOutputStream()发送内容。
Content-Type
表示后面的文档属于什么MIME类型。Servlet默认为text/plain，但通常需要显式地指定为text/html。由于经常要设置Content-Type，因此HttpServletResponse提供了一个专用的方法setContentTyep。
Date
当前的GMT时间。你可以用setDateHeader来设置这个头以避免转换时间格式的麻烦。
Expires
应该在什么时候认为文档已经过期，从而不再缓存它？
Last-Modified
文档的最后改动时间。客户可以通过If-Modified-Since请求头提供一个日期，该请求将被视为一个条件 GET，只有改动时间迟于指定时间的文档才会返回，否则返回一个304（Not Modified）状态。Last-Modified也可用setDateHeader方法来设置。
Location
表示客户应当到哪里去提取文档。Location通常不是直接设置的，而是通过HttpServletResponse的sendRedirect方法，该方法同时设置状态代码为302。
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都支持它。
Server
服务器名字。Servlet一般不设置这个值，而是由Web服务器自己设置。
Set-Cookie
设置和页面关联的Cookie。Servlet不应使用response.setHeader("Set-Cookie", ...)，而是应使用HttpServletResponse提供的专用方法addCookie。参见下文有关Cookie设置的讨论。
WWW-Authenticate
客户应该在Authorization头中提供什么类型的授权信息？在包含401（Unauthorized）状态行的应答中这个头是必需的。例如，response.setHeader("WWW-Authenticate", "BASIC realm=＼"executives＼"")。
 注意Servlet一般不进行这方面的处理，而是让Web服务器的专门机制来控制受密码保护页面的访问（例如.htaccess）。
 
  
 
  
 
 HTTP请求头概述 （HttpServletRequest） HTTP客户程序（例如浏览器），向服务器发送请求的时候必须指明请求类型（一般是GET或者POST或者HEAD）。
 　　如有必要，客户程序还可以选择发送其他的请求头。大多数请求头并不是必需的，但Content-Length除外。对于POST请求来说Content-Length必须出现。 下面是一些最常见的请HTTP请求头概述 （HttpServletRequest）
 　　HTTP客户程序（例如浏览器），向服务器发送请求的时候必须指明请求类型（一般是GET或者 POST）。如有必要，客户程序还可以选择发送其他的请求头。大多数请求头并不是必需的，但Content-Length除外。对于POST请求来说 Content-Length必须出现。
 　　下面是一些最常见的请求头
 　　Accept：浏览器可接受的MIME类型。
 　　Accept-Charset：浏览器可接受的字符集。
 　　Accept-Encoding：浏览器能够进行解码的数据编码方式，比如gzip。Servlet能够向支持gzip的浏览器返回经gzip编码的HTML页面。许多情形下这可以减少5到10倍的下载时间。
 　　Accept-Language：浏览器所希望的语言种类，当服务器能够提供一种以上的语言版本时要用到。
 　　Authorization：授权信息，通常出现在对服务器发送的WWW-Authenticate头的应答中。
 　　Connection：表示是否需要持久连接。如果Servlet看到这里的值为“Keep- Alive”，或者看到请求使用的是HTTP 1.1（HTTP 1.1默认进行持久连接），它就可以利用持久连接的优点，当页面包含多个元素时（例如Applet，图片），显著地减少下载所需要的时间。要实现这一点，Servlet需要在应答中发送一个Content-Length头，最简单的实现方法是：先把内容写入 ByteArrayOutputStream，然后在正式写出内容之前计算它的大小。
 　　Content-Length：表示请求消息正文的长度。
 　　Cookie：这是最重要的请求头信息之一
 　　From：请求发送者的email地址，由一些特殊的Web客户程序使用，浏览器不会用到它。
 　　Host：初始URL中的主机和端口。
 　　If-Modified-Since：只有当所请求的内容在指定的日期之后又经过修改才返回它，否则返回304“Not Modified”应答。
 　　Pragma：指定“no-cache”值表示服务器必须返回一个刷新后的文档，即使它是代理服务器而且已经有了页面的本地拷贝。
 　　Referer：包含一个URL，用户从该URL代表的页面出发访问当前请求的页面。
 　　User-Agent：浏览器类型，如果Servlet返回的内容与浏览器类型有关则该值非常有用。
 　　UA-Pixels，UA-Color，UA-OS，UA-CPU：由某些版本的IE浏览器所发送的非标准的请求头，表示屏幕大小、颜色深度、操作系统和CPU类型。
 　　HTTP应答头概述（HttpServletResponse）
 　　Web服务器的HTTP应答一般由以下几项构成：一个状态行，一个或多个应答头，一个空行，内容文档。设置HTTP应答头往往和设置状态行中的状态代码结合起来。例如，有好几个表示“文档位置已经改变”的状态代码都伴随着一个Location头，而401（Unauthorized）状态代码则必须伴随一个WWW-Authenticate头。
 　　然而，即使在没有设置特殊含义的状态代码时，指定应答头也是很有用的。应答头可以用来完成：设置Cookie，指定修改日期，指示浏览器按照指定的间隔刷新页面，声明文档的长度以便利用持久HTTP连接，……等等许多其他任务。
 　　设置应答头最常用的方法是HttpServletResponse的setHeader，该方法有两个参数，分别表示应答头的名字和值。和设置状态代码相似，设置应答头应该在发送任何文档内容之前进行。
 　　setDateHeader方法和setIntHeadr方法专门用来设置包含日期和整数值的应答头，前者避免了把Java时间转换为GMT时间字符串的麻烦，后者则避免了把整数转换为字符串的麻烦。
 　　HttpServletResponse还提供了许多设置
 　　setContentType：设置Content-Type头。大多数Servlet都要用到这个方法。
 　　setContentLength：设置Content-Length头。对于支持持久HTTP连接的浏览器来说，这个函数是很有用的。
 　　addCookie：设置一个Cookie（Servlet API中没有setCookie方法，因为应答往往包含多个Set-Cookie头）。
 　　另外，如上节介绍，sendRedirect方法设置状态代码302时也会设置Location头。
 　　HTTP应答头 说明
 　　Allow 服务器支持哪些请求方法（如GET、POST等）。
 　　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页面，为其他浏览器返回普通页面。
 　　 Content-Length 表示内容长度。只有当浏览器使用持久HTTP连接时才需要这个数据。如果你想要利用持久连接的优势，可以把输出文档写入 ByteArrayOutputStram，完成后查看其大小，然后把该值放入Content-Length头，最后通过 byteArrayStream.writeTo(response.getOutputStream()发送内容。
 　　Content- Type 表示后面的文档属于什么MIME类型。Servlet默认为text/plain，但通常需要显式地指定为text/html。由于经常要设置 Content-Type，因此HttpServletResponse提供了一个专用的方法setContentTyep。
 　　Date 当前的GMT时间。你可以用setDateHeader来设置这个头以避免转换时间格式的麻烦。
 　　Expires 应该在什么时候认为文档已经过期，从而不再缓存它？
 　　Last-Modified 文档的最后改动时间。客户可以通过If-Modified-Since请求头提供一个日期，该请求将被视为一个条件GET，只有改动时间迟于指定时间的文档才会返回，否则返回一个304（Not Modified）状态。Last-Modified也可用setDateHeader方法来设置。
 　　Location 表示客户应当到哪里去提取文档。Location通常不是直接设置的，而是通过HttpServletResponse的sendRedirect方法，该方法同时设置状态代码为302。
 　　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都支持它。
 　　Server 服务器名字。Servlet一般不设置这个值，而是由Web服务器自己设置。
 　　Set-Cookie 设置和页面关联的Cookie。Servlet不应使用response.setHeader("Set-Cookie", ...)，而是应使用HttpServletResponse提供的专用方法addCookie。参见下文有关Cookie设置的讨论。
 　　 WWW-Authenticate 客户应该在Authorization头中提供什么类型的授权信息？在包含401（Unauthorized）状态行的应答中这个头是必需的。例如，response.setHeader("WWW-Authenticate", "BASIC realm=\"executives\"")。注意Servlet一般不进行这方面的处理，而是让Web服务器的专门机制来控制受密码保护页面的访问（例如.htaccess）。
 
 错误代码解释
 　　"100" : Continue
 　　"101" : witching Protocols
 　　"200" : OK
 　　"201" : Created
 　　"202" : Accepted
 　　"203" : Non-Authoritative Information
 　　"204" : No Content
 　　"205" : Reset Content
 　　"206" : Partial Content
 　　"300" : Multiple Choices
 　　"301" : Moved Permanently
 　　"302" : Found
 　　"303" : See Other
 　　"304" : Not Modified
 　　"305" : Use Proxy
 　　"307" : Temporary Redirect
 　　HTTP 400 - 请求无效
 　　HTTP 401.1 - 未授权：登录失败
 　　HTTP 401.2 - 未授权：服务器配置问题导致登录失败
 　　HTTP 401.3 - ACL 禁止访问资源
 　　HTTP 401.4 - 未授权：授权被筛选器拒绝
 　　HTTP 401.5 - 未授权：ISAPI 或 CGI 授权失败
 　　HTTP 403 - 禁止访问
 　　HTTP 403 - 对 Internet 服务管理器 (HTML) 的访问仅限于 Localhost
 　　HTTP 403.1 禁止访问：禁止可执行访问
 　　HTTP 403.2 - 禁止访问：禁止读访问
 　　HTTP 403.3 - 禁止访问：禁止写访问
 　　HTTP 403.4 - 禁止访问：要求 SSL
 　　HTTP 403.5 - 禁止访问：要求 SSL 128
 　　HTTP 403.6 - 禁止访问：IP 地址被拒绝
 　　HTTP 403.7 - 禁止访问：要求客户证书
 　　HTTP 403.8 - 禁止访问：禁止站点访问
 　　HTTP 403.9 - 禁止访问：连接的用户过多
 　　HTTP 403.10 - 禁止访问：配置无效
 　　HTTP 403.11 - 禁止访问：密码更改
 　　HTTP 403.12 - 禁止访问：映射器拒绝访问
 　　HTTP 403.13 - 禁止访问：客户证书已被吊销
 　　HTTP 403.15 - 禁止访问：客户访问许可过多
 　　HTTP 403.16 - 禁止访问：客户证书不可信或者无效
 　　HTTP 403.17 - 禁止访问：客户证书已经到期或者尚未生效
 　　HTTP 404.1 - 无法找到 Web 站点
 　　HTTP 404 - 无法找到文件
 　　HTTP 405 - 资源被禁止
 　　HTTP 406 - 无法接受
 　　HTTP 407 - 要求代理身份验证
 　　HTTP 410 - 永远不可用
 　　HTTP 412 - 先决条件失败
 　　HTTP 414 - 请求 - URI 太长
 　　HTTP 500 - 内部服务器错误
 　　HTTP 500.100 - 内部服务器错误 - ASP 错误
 　　HTTP 500-11 服务器关闭
 　　HTTP 500-12 应用程序重新启动
 　　HTTP 500-13 - 服务器太忙
 　　HTTP 500-14 - 应用程序无效
 　　HTTP 500-15 - 不允许请求 global.asa
 　　Error 501 - 未实现
 　　HTTP 502 - 网关错误

 
 

   引用
 
 
 

   学习Web开发不好好学习HTTP报文，将会“打拳不练功，到老一场空”，你花在犯迷糊上的时间比你沉下心来学习HTTP的时间肯定会多很多。
 
 
 
 
 HTTP请求报文解剖
  
 
 
 
 
 HTTP请求报文由3部分组成（
 请求行+请求头+请求体
 ）： 
 
 
 
 
 
  
 
 
 
 
 下面是一个实际的请求报文： 
 
 
 
 
 
  
 
 
 
 
 ①是请求方法，GET和POST是最常见的HTTP方法，除此以外还包括DELETE、HEAD、OPTIONS、PUT、TRACE。不过，当前的大多数浏览器只支持GET和POST，Spring 3.0提供了一个HiddenHttpMethodFilter，允许你通过“_method”的表单参数指定这些特殊的HTTP方法（实际上还是通过POST提交表单）。服务端配置了HiddenHttpMethodFilter后，Spring会根据_method参数指定的值模拟出相应的HTTP方法，这样，就可以使用这些HTTP方法对处理方法进行映射了。 
 
 
 
 
 ②为请求对应的URL地址，它和报文头的Host属性组成完整的请求URL，③是协议名称及版本号。 
 
 
 
 
 ④是HTTP的报文头，报文头包含若干个属性，格式为“属性名:属性值”，服务端据此获取客户端的信息。 
 
 
 
 
 ⑤是报文体，它将一个页面表单中的组件值通过param1=value1&param2=value2的键值对形式编码成一个格式化串，它承载多个请求参数的数据。不但报文体可以传递请求参数，请求URL也可以通过类似于“/chapter15/user.html? param1=value1&param2=value2”的方式传递请求参数。 
 
 
 
 
 对照上面的请求报文，我们把它进一步分解，你可以看到一幅更详细的结构图： 
 
 
 
 
 
  
 
 
 
 
 
 
 

   引用
 
 
 
 
  HttpWatch是强大的网页数据分析工具，安装后将集成到Internet Explorer工具栏中。它不用代理服务器或一些复杂的网络监控工具，就能抓取请求及响应的完整信息，包括Cookies、消息头、查询参数、响应报文等，是Web应用开发人员的必备工具。
 
 
 
 
 
 
 HTTP请求报文头属性
  
 
 
 
 
 报文头属性是什么东西呢？我们不妨以一个小故事来说明吧。 
 
 
 
 
 

   引用
 
 
 

   快到中午了，张三丰不想去食堂吃饭，于是打电话叫外卖：老板，我要一份[鱼香肉丝]，要12：30之前给我送过来哦，我在江湖湖公司研发部，叫张三丰。
 
 
 
 
 
 
 这里，你要[鱼香肉丝]相当于HTTP报文体，而“12：30之前送过来”，你叫“张三丰”等信息就相当于HTTP的报文头。它们是一些附属信息，帮忙你和饭店老板顺利完成这次交易。 
 
 
 
 
 请求HTTP报文和响应HTTP报文都拥有若干个报文关属性，它们是为协助客户端及服务端交易的一些附属信息。 
 
 
 
 
 
 
 常见的HTTP请求报文头属性
  
 
 
 
 
 Accept
  
 
 
 
 
 请求报文可通过一个“Accept”报文头属性告诉服务端 客户端接受什么类型的响应。 
 
 
 
 
 如下报文头相当于告诉服务端，俺客户端能够接受的响应类型仅为纯文本数据啊，你丫别发其它什么图片啊，视频啊过来，那样我会歇菜的~~~： 
 
 
 
 
 
 
  
 
   

     Java代码  
    
   
 
  
 
  
 Accept:text/plain  
 
  

   
  
 
 
 
 
 
 
 
 Accept属性的值可以为一个或多个MIME类型的值，关于MIME类型，大家请参考：
 http://en.wikipedia.org/wiki/MIME_type
  
 
 
 
 
 Cookie
  
 
 
 
 
 客户端的Cookie就是通过这个报文头属性传给服务端的哦！如下所示： 
 
 
 
 
  
 
   

     Java代码  
    
   
 
  
 
  
 Cookie: $Version=1; Skin=new;jsessionid=5F4771183629C9834F8382E23BE13C4C  
 
  

   
  
 
 
 
 
 
 服务端是怎么知道客户端的多个请求是隶属于一个Session呢？注意到后台的那个jsessionid=5F4771183629C9834F8382E23BE13C4C木有？原来就是通过HTTP请求报文头的Cookie属性的jsessionid的值关联起来的！（当然也可以通过重写URL的方式将会话ID附带在每个URL的后面哦）。 
 
 
 
 
 
 
 Referer
  
 
 
 
 
 表示这个请求是从哪个URL过来的，假如你通过google搜索出一个商家的广告页面，你对这个广告页面感兴趣，鼠标一点发送一个请求报文到商家的网站，这个请求报文的Referer报文头属性值就是http://www.google.com。 
 
 
 

   引用
 
 
 
 
  
 唐僧到了西天. 
  
 如来问：侬是不是从东土大唐来啊？ 
  
 唐僧：厉害！你咋知道的！ 
  
 如来：呵呵，我偷看了你的Referer... 
  
 
 
 
 
 
 
 
 很多貌似神奇的网页监控软件（如著名的 
 我要啦
 ），只要在你的网页上放上一段JavaScript，就可以帮你监控流量，全国访问客户的分布情况等报表和图表，其原理就是通过这个Referer及其它一些HTTP报文头工作的。 
 
 
 
 
 Cache-Control
  
 
 
 
 
 对缓存进行控制，如一个请求希望响应返回的内容在客户端要被缓存一年，或不希望被缓存就可以通过这个报文头达到目的。 
 
 
 
 
 如以下设置，相当于让服务端将对应请求返回的响应内容不要在客户端缓存： 
 
 
 
 
  
 
   

     Java代码  
    
   
 
  
 
  
 Cache-Control: no-cache  
 
  

   
  
 
 
 
 
 
 
 
 其它请求报文头属性
  
 
 
 
 
 参见：
 http://en.wikipedia.org/wiki/List_of_HTTP_header_fields
  
 
 
 
 
 如何访问请求报文头
  
 
 
 
 
 由于请求报文头是客户端发过来的，服务端当然只能读取了，以下是HttpServletRequest一些用于读取请求报文头的API： 
 
 
 
 
 
 
  
 
   

     Java代码  
    
   
 
  
 
  
 //获取请求报文中的属性名称  
 java.util.Enumeration<java.lang.String>   getHeaderNames();  
   
 //获取指定名称的报文头属性的值  
 java.lang.String getHeader(java.lang.String name)   
 
  

   
  
 
 
 
 
 
 
 
 由于一些请求报文头属性“太著名”了，因此HttpServletRequest为它们提供了VIP的API： 
 
 
 
 
 
 
  
 
   

     Java代码  
    
   
 
  
 
  
 //获取报文头中的Cookie(读取Cookie的报文头属性）  
  Cookie[]   getCookies() ;  
   
 //获取客户端本地化信息（读取 Accept-Language 的报文头属性）  
 java.util.Locale    getLocale()   
   
 //获取请求报文体的长度（读取Content-Length的报文头属性）  
 int getContentLength();  
 
  

   
  
 
 
 
 
 
 
 
 HttpServletRequest可以通过 
 
 
 
 
  
 
   

     Java代码  
    
   
 
  
 
  
 HttpSession getSession()   
 
  

   
  
 
 
 
 
 
 获取请求所关联的HttpSession,其内部的机理是通过读取请求报文头中Cookie属性的JSESSIONID的值，在服务端的一个会话Map中，根据这个JSESSIONID获取对应的HttpSession的对象。（这样，你就不会觉得HttpSession很神秘了吧，你自己也可以做一个类似的会话管理 
 
  ） 
 
 
 
 
 HTTP响应报文解剖
  
 
 
 
 
 响应报文结构
  
 
 
 
 
 HTTP的响应报文也由三部分组成（
 响应行+响应头+响应体
 ）： 
 
 
 
 
 
  
 
 
 
 
 以下是一个实际的HTTP响应报文： 
 
 
 
 
 
  
 
 
 
 
 ①报文协议及版本； 
 
 
 ②状态码及状态描述； 
 
 
 ③响应报文头，也是由多个属性组成； 
 
 
 ④响应报文体，即我们真正要的“干货”。 
 
 
 
 
 响应状态码
  
 
 
 
 
 和请求报文相比，响应报文多了一个“响应状态码”，它以“清晰明确”的语言告诉客户端本次请求的处理结果。 
 
 
 
 
 HTTP的响应状态码由5段组成： 
 
 
 
 
 
 1xx 消息，一般是告诉客户端，请求已经收到了，正在处理，别急...
 2xx 处理成功，一般表示：请求收悉、我明白你要的、请求已受理、已经处理完成等信息.
 3xx 重定向到其它地方。它让客户端再发起一个请求以完成整个处理。
 4xx 处理发生错误，责任在客户端，如客户端的请求一个不存在的资源，客户端未被授权，禁止访问等。
 5xx 处理发生错误，责任在服务端，如服务端抛出异常，路由出错，HTTP版本不支持等。
 
 
 
 
 
 以下是几个常见的状态码： 
 
 
 
 
 200 OK
  
 
 
 
 
 你最希望看到的，即处理成功！ 
 
 
 
 
 303 See Other
  
 
 
 
 
 我把你redirect到其它的页面，目标的URL通过响应报文头的Location告诉你。 
 
 
 

   引用
 
 
 

   悟空：师傅给个桃吧，走了一天了
   
  
 唐僧：我哪有桃啊！去王母娘娘那找吧
  
 
 
 
 
 
 
 304 Not Modified
  
 
 
 
 
 告诉客户端，你请求的这个资源至你上次取得后，并没有更改，你直接用你本地的缓存吧，我很忙哦，你能不能少来烦我啊！ 
 
 
 
 
 404 Not Found
  
 
 
 
 
 你最不希望看到的，即找不到页面。如你在google上找到一个页面，点击这个链接返回404，表示这个页面已经被网站删除了，google那边的记录只是美好的回忆。 
 
 
 
 
 500 Internal Server Error
  
 
 
 
 
 看到这个错误，你就应该查查服务端的日志了，肯定抛出了一堆异常，别睡了，起来改BUG去吧！ 
 
 
 
 
 
 
 其它的状态码参见：
 http://en.wikipedia.org/wiki/List_of_HTTP_status_codes
  
 
 
 
 
 
 
 有些响应码，Web应用服务器会自动给生成。你可以通过HttpServletResponse的API设置状态码： 
 
 
 
 
 
 
  
 
   

     Java代码  
    
   
 
  
 
  
 //设置状态码，状态码在HttpServletResponse中通过一系列的常量预定义了，如SC_ACCEPTED，SC_OK  
 void    setStatus(int sc)   
 
  

   
  
 
 
 
 
 
 
 
 常见的HTTP响应报文头属性
  
 
 
 
 
 Cache-Control
  
 
 
 
 
 响应输出到客户端后，服务端通过该报文头属告诉客户端如何控制响应内容的缓存。 
 
 
 
 
 下面，的设置让客户端对响应内容缓存3600秒，也即在3600秒内，如果客户再次访问该资源，直接从客户端的缓存中返回内容给客户，不要再从服务端获取
 （当然，这个功能是靠客户端实现的，服务端只是通过这个属性提示客户端“应该这么做”，做不做，还是决定于客户端，如果是自己宣称支持HTTP的客户端，则就应该这样实现）
 。 
 
 
 
 
 
 
  
 
   

     Java代码  
    
   
 
  
 
  
 Cache-Control: max-age=3600  
 
  

   
  
 
 
 
 
 
 
 
 ETag
  
 
 
 
 
 一个代表响应服务端资源（如页面）版本的报文头属性，如果某个服务端资源发生变化了，这个ETag就会相应发生变化。它是Cache-Control的有益补充，可以让客户端“更智能”地处理什么时候要从服务端取资源，什么时候可以直接从缓存中返回响应。 
 
 
 
 
 关于ETag的说明，你可以参见：
 http://en.wikipedia.org/wiki/HTTP_ETag
 。 
 
 
 Spring 3.0还专门为此提供了一个org.springframework.web.filter.ShallowEtagHeaderFilter（实现原理很简单，对JSP输出的内容MD5，这样内容有变化ETag就相应变化了），用于生成响应的ETag，因为这东东确实可以帮助减少请求和响应的交互。 
 
 
 
 
 下面是一个ETag： 
 
 
 
 
  
 
   

     Java代码  
    
   
 
  
 
  
 ETag: "737060cd8c284d8af7ad3082f209582d"  
 
  

   
  
 
 
 
 
 
 
 
 Location
  
 
 
 
 
 我们在JSP中让页面Redirect到一个某个A页面中，其实是让客户端再发一个请求到A页面，这个需要Redirect到的A页面的URL，其实就是通过响应报文头的Location属性告知客户端的，如下的报文头属性，将使客户端redirect到iteye的首页中： 
 
 
 
 
 
 
  
 
   

     Java代码  
    
   
 
  
 
  
 Location: http://www.iteye.com  
 
  

   
  
 
 
 
 
 
 
 
 Set-Cookie
  
 
 
 
 
 服务端可以设置客户端的Cookie，其原理就是通过这个响应报文头属性实现的： 
 
 
 
 
 
 
  
 
   

     Java代码  
    
   
 
  
 
  
 Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1  
 
  

   
  
 
 
 
 
 
 
 
 
 
 其它HTTP响应报文头属性
  
 
 
 
 
 更多其它的HTTP响应头报文，参见：
 http://en.wikipedia.org/wiki/List_of_HTTP_header_fields
  
 
 
 
 
 
 
 如何写HTTP请求报文头
  
 
 
 
 
 在服务端可以通过HttpServletResponse的API写响应报文头的属性： 
 
 
 
 
 
 
  
 
   

     Java代码  
    
   
 
  
 
  
 //添加一个响应报文头属性  
 void    setHeader(String name, String value)   
 
  

   
  
 
 
 
 
 
 
 
 象Cookie，Location这些响应都是有福之人，HttpServletResponse为它们都提供了VIP版的API： 
 
 
 
 
  
 
   

     Java代码  
    
   
 
  
 
  
 //添加Cookie报文头属性  
 void addCookie(Cookie cookie)   
   
 //不但会设置Location的响应报文头，还会生成303的状态码呢，两者天仙配呢  
 void    sendRedirect(String location)   
 
  

   
  
 
 
 
 
 

 
 
 
作为一名前端开发人员，肯定少不了要和网络打交道，因为要从服务器端拉取数据，从服务端获取数据最常用的方式还是通过HTTP请求。给服务器发请求的时候有请求头，接受服务器响应的时候有响应头，客户端和服务器端互相沟通需要的信息都是通过这些“头”来传送，这些信息是一些类似key:value的键值对。了解这些“头”中字段的含义对于理解整个请求过程有很大的帮助。这里列举了常用的“头”字段的解释以及例子，本文可以作为工具文收藏，以备需要时查看。
 
常用标准请求头字段#####
 

Accept 设置接受的内容类型
 
 
 
Accept: text/plain
 
 
Accept-Charset 设置接受的字符编码
 
 
 
Accept-Charset: utf-8
 
 
Accept-Encoding 设置接受的编码格式
 
 
 
Accept-Encoding: gzip, deflate
 
 
Accept-Datetime 设置接受的版本时间
 
 
 
Accept-Datetime: Thu, 31 May 2007 20:35:00 GMT
 
 
Accept-Language 设置接受的语言
 
 
 
Accept-Language: en-US
 
 
Authorization 设置HTTP身份验证的凭证
 
 
 
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
 
 
Cache-Control 设置请求响应链上所有的缓存机制必须遵守的指令
 
 
 
Cache-Control: no-cache
 
 
Connection 设置当前连接和hop-by-hop协议请求字段列表的控制选项
 
 
 
Connection: keep-alive
 Connection: Upgrade
 
 
Content-Length 设置请求体的字节长度
 
 
 
Content-Length: 348
 
 
Content-MD5 设置基于MD5算法对请求体内容进行Base64二进制编码
 
 
 
Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
 
 
Content-Type 设置请求体的MIME类型（适用POST和PUT请求）
 
 
 
Content-Type: application/x-www-form-urlencoded
 
 
Cookie 设置服务器使用Set-Cookie发送的http cookie
 
 
 
Cookie: $Version=1; Skin=new;
 
 
Date 设置消息发送的日期和时间
 
 
 
Date: Tue, 15 Nov 1994 08:12:31 GMT
 
 
Expect 标识客户端需要的特殊浏览器行为
 
 
 
Expect: 100-continue
 
 
Forwarded 披露客户端通过http代理连接web服务的源信息
 
 
 
Forwarded: for=192.0.2.60;proto=http;by=203.0.113.43
 Forwarded: for=192.0.2.43, for=198.51.100.17
 
 
From 设置发送请求的用户的email地址
 
 
 
From: user@example.com
 
 
Host 设置服务器域名和TCP端口号，如果使用的是服务请求标准端口号，端口号可以省略
 
 
 
Host: en.wikipedia.org:8080
 Host: en.wikipedia.org
 
 
If-Match 设置客户端的ETag,当时客户端ETag和服务器生成的ETag一致才执行，适用于更新自从上次更新之后没有改变的资源
 
 
 
If-Match: "737060cd8c284d8af7ad3082f209582d
 
 
If-Modified-Since 设置更新时间，从更新时间到服务端接受请求这段时间内如果资源没有改变，允许服务端返回304 Not Modified
 
 
 
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
 
 
If-None-Match 设置客户端ETag，如果和服务端接受请求生成的ETage相同，允许服务端返回304 Not Modified
 
 
 
If-None-Match: "737060cd8c284d8af7ad3082f209582d"
 
 
If-Range 设置客户端ETag，如果和服务端接受请求生成的ETage相同，返回缺失的实体部分；否则返回整个新的实体
 
 
 
If-Range: "737060cd8c284d8af7ad3082f209582d"
 
 
If-Unmodified-Since 设置更新时间，只有从更新时间到服务端接受请求这段时间内实体没有改变，服务端才会发送响应
 
 
 
If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
 
 
Max-Forwards 限制代理或网关转发消息的次数
 
 
 
Max-Forwards: 10
 
 
Origin 标识跨域资源请求（请求服务端设置Access-Control-Allow-Origin响应字段）
 
 
 
Origin: http://www.example-social-network.com
 
 
Pragma 设置特殊实现字段，可能会对请求响应链有多种影响
 
 
 
Pragma: no-cache
 
 
Proxy-Authorization 为连接代理授权认证信息
 
 
 
Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
 
 
Range 请求部分实体，设置请求实体的字节数范围，具体可以参见HTTP/1.1中的Byte serving
 
 
 
Range: bytes=500-999
 
 
Referer 设置前一个页面的地址，并且前一个页面中的连接指向当前请求，意思就是如果当前请求是在A页面中发送的，那么referer就是A页面的url地址（轶事：这个单词正确的拼法应该是"referrer",但是在很多规范中都拼成了"referer"，所以这个单词也就成为标准用法）
 
 
 
Referer: http://en.wikipedia.org/wiki/Main_Page
 
 
TE 设置用户代理期望接受的传输编码格式，和响应头中的Transfer-Encoding字段一样
 
 
 
TE: trailers, deflate
 
 
Upgrade 请求服务端升级协议
 
 
 
Upgrade: HTTP/2.0, HTTPS/1.3, IRC/6.9, RTA/x11, websocket
 
 
User-Agent 用户代理的字符串值
 
 
 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/21.0
 
 
Via 通知服务器代理请求
 
 
 
Via: 1.0 fred, 1.1 example.com (Apache/1.1)
 
 
Warning 实体可能会发生的问题的通用警告
 
 
 
Warning: 199 Miscellaneous warning
 
 
常用非标准请求头字段#####
 

X-Requested-With 标识Ajax请求，大部分js框架发送请求时都会设置它为XMLHttpRequest
 
 
 
X-Requested-With: XMLHttpRequest
 
 
DNT 请求web应用禁用用户追踪
 
 
 
DNT: 1 (Do Not Track Enabled)
 DNT: 0 (Do Not Track Disabled)
 
 
X-Forwarded-For 一个事实标准，用来标识客户端通过HTTP代理或者负载均衡器连接的web服务器的原始IP地址
 
 
 
X-Forwarded-For: client1, proxy1, proxy2
 X-Forwarded-For: 129.78.138.66, 129.78.64.103
 
 
X-Forwarded-Host 一个事实标准，用来标识客户端在HTTP请求头中请求的原始host,因为主机名或者反向代理的端口可能与处理请求的原始服务器不同
 
 
 
X-Forwarded-Host: en.wikipedia.org:8080
 X-Forwarded-Host: en.wikipedia.org
 
 
X-Forwarded-Proto 一个事实标准，用来标识HTTP原始协议，因为反向代理或者负载均衡器和web服务器可能使用http,但是请求到反向代理使用的是https
 
 
 
X-Forwarded-Proto: https
 
 
Front-End-Https 微软应用程序和负载均衡器使用的非标准header字段 Front-End-Https: on
X-Http-Method-Override 请求web应用时，使用header字段中给定的方法（通常是put或者delete）覆盖请求中指定的方法（通常是post）,如果用户代理或者防火墙不支持直接使用put或者delete方法发送请求时，可以使用这个字段
 
 
 
X-HTTP-Method-Override: DELETE
 
 
X-ATT-DeviceId 允许更简单的解析用户代理在AT&T设备上的MakeModel/Firmware
 
 
 
X-Att-Deviceid: GT-P7320/P7320XXLPG
 
 
X-Wap-Profile 设置描述当前连接设备的详细信息的xml文件在网络中的位置
 
 
 
x-wap-profile: http://wap.samsungmobile.com/uaprof/SGH-I777.xml
 
 
Proxy-Connection 早起HTTP版本中的一个误称，现在使用标准的connection字段
 
 
 
Proxy-Connection: keep-alive
 
 
X-UIDH 服务端深度包检测插入的一个唯一ID标识Verizon Wireless的客户
 
 
 
X-UIDH: ...
 
 
X-Csrf-Token,X-CSRFToken,X-XSRF-TOKEN 防止跨站请求伪造
 
 
 
X-Csrf-Token: i8XNjC4b8KVok4uw5RftR38Wgp2BFwql
 
 
X-Request-ID,X-Correlation-ID 标识客户端和服务端的HTTP请求
 
 
 
X-Request-ID: f058ebd6-02f7-4d3f-942e-904344e8cde5
 
 
常用标准响应头字段#####
 

Access-Control-Allow-Origin 指定哪些站点可以参与跨站资源共享
 
 
 
Access-Control-Allow-Origin: *
 
 
Accept-Patch 指定服务器支持的补丁文档格式，适用于http的patch方法
 
 
 
Accept-Patch: text/example;charset=utf-8
 
 
Accept-Ranges 服务器通过byte serving支持的部分内容范围类型
 
 
 
Accept-Ranges: bytes
 
 
Age 对象在代理缓存中暂存的秒数
 
 
 
Age: 12
 
 
Allow 设置特定资源的有效行为，适用方法不被允许的http 405错误
 
 
 
Allow: GET, HEAD
 
 
Alt-Svc 服务器使用"Alt-Svc"（Alternative Servicesde的缩写）头标识资源可以通过不同的网络位置或者不同的网络协议获取
 
 
 
Alt-Svc: h2="http2.example.com:443"; ma=7200
 
 
Cache-Control 告诉服务端到客户端所有的缓存机制是否可以缓存这个对象，单位是秒
 
 
 
Cache-Control: max-age=3600
 
 
Connection 设置当前连接和hop-by-hop协议请求字段列表的控制选项
 
 
 
Connection: close
 
 
Content-Disposition 告诉客户端弹出一个文件下载框，并且可以指定下载文件名
 
 
 
Content-Disposition: attachment; filename="fname.ext"
 
 
Content-Encoding 设置数据使用的编码类型
 
 
 
Content-Encoding: gzip
 
 
Content-Language 为封闭内容设置自然语言或者目标用户语言
 
 
 
Content-Language: en
 
 
Content-Length 响应体的字节长度
 
 
 
Content-Length: 348
 
 
Content-Location 设置返回数据的另一个位置
 
 
 
Content-Location: /index.htm
 
 
Content-MD5 设置基于MD5算法对响应体内容进行Base64二进制编码
 
 
 
Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
 
 
Content-Range 标识响应体内容属于完整消息体中的那一部分
 
 
 
Content-Range: bytes 21010-47021/47022
 
 
Content-Type 设置响应体的MIME类型
 
 
 
Content-Type: text/html; charset=utf-8
 
 
Date 设置消息发送的日期和时间
 
 
 
Date: Tue, 15 Nov 1994 08:12:31 GMT
 
 
ETag 特定版本资源的标识符，通常是消息摘要
 
 
 
ETag: "737060cd8c284d8af7ad3082f209582d"
 
 
Expires 设置响应体的过期时间
 
 
 
Expires: Thu, 01 Dec 1994 16:00:00 GMT
 
 
Last-Modified 设置请求对象最后一次的修改日期
 
 
 
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
 
 
Link 设置与其他资源的类型关系
 
 
 
Link: </feed>; rel="alternate"
 
 
Location 在重定向中或者创建新资源时使用
 
 
 
Location: http://www.w3.org/pub/WWW/People.html
 
 
P3P 以P3P:CP="your_compact_policy"的格式设置支持P3P(Platform for Privacy Preferences Project)策略，大部分浏览器没有完全支持P3P策略，许多站点设置假的策略内容欺骗支持P3P策略的浏览器以获取第三方cookie的授权
 
 
 
P3P: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info."
 
 
Pragma 设置特殊实现字段，可能会对请求响应链有多种影响
 
 
 
Pragma: no-cache
 
 
Proxy-Authenticate 设置访问代理的请求权限
 
 
 
Proxy-Authenticate: Basic
 
 
Public-Key-Pins 设置站点的授权TLS证书
 
 
 
Public-Key-Pins: max-age=2592000; pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g=";
 
 
Refresh "重定向或者新资源创建时使用，在页面的头部有个扩展可以实现相似的功能，并且大部分浏览器都支持
<meta http-equiv="refresh" content="5; url=http://example.com/">
 
 
 
Refresh: 5; url=http://www.w3.org/pub/WWW/People.html
 
 
Retry-After 如果实体暂时不可用，可以设置这个值让客户端重试，可以使用时间段（单位是秒）或者HTTP时间
 
 
 
Example 1: Retry-After: 120
 Example 2: Retry-After: Fri, 07 Nov 2014 23:59:59 GMT
 
 
Server 服务器名称
 
 
 
Server: Apache/2.4.1 (Unix)
 
 
Set-Cookie 设置HTTP Cookie
 
 
 
Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1
 
 
Status 设置HTTP响应状态
 
 
 
Status: 200 OK
 
 
Strict-Transport-Security 一种HSTS策略通知HTTP客户端缓存HTTPS策略多长时间以及是否应用到子域
 
 
 
Strict-Transport-Security: max-age=16070400; includeSubDomains
 
 
Trailer 标识给定的header字段将展示在后续的chunked编码的消息中
 
 
 
Trailer: Max-Forwards
 
 
Transfer-Encoding 设置传输实体的编码格式，目前支持的格式： chunked, compress, deflate, gzip, identity
 
 
 
Transfer-Encoding: chunked
 
 
TSV Tracking Status Value，在响应中设置给DNT(do-not-track),可能的取值

 　　　"!" — under construction

 　　　"?" — dynamic

 　　　"G" — gateway to multiple parties

 　　　"N" — not tracking

 　　　"T" — tracking

 　　　"C" — tracking with consent

 　　　"P" — tracking only if consented

 　　　"D" — disregarding DNT

 　　　"U" — updated
 
 
 
TSV: ?
 
 
Upgrade 请求客户端升级协议
 
 
 
Upgrade: HTTP/2.0, HTTPS/1.3, IRC/6.9, RTA/x11, websocket
 
 
Vary 通知下级代理如何匹配未来的请求头已让其决定缓存的响应是否可用而不是重新从源主机请求新的
 
 
 
Example 1: Vary: *
 Example 2: Vary: Accept-Language
 
 
Via 通知客户端代理，通过其要发送什么响应
 
 
 
Via: 1.0 fred, 1.1 example.com (Apache/1.1)
 
 
Warning 实体可能会发生的问题的通用警告
 
 
 
Warning: 199 Miscellaneous warning
 
 
WWW-Authenticate 标识访问请求实体的身份验证方案
 
 
 
WWW-Authenticate: Basic
 
 
X-Frame-Options 点击劫持保护：

 　　　deny frame中不渲染

 　　　sameorigin 如果源不匹配不渲染

 　　　allow-from 允许指定位置访问

 　　　allowall 不标准，允许任意位置访问
 
 
 
X-Frame-Options: deny
 
 
常用非标准响应头字段#####
 

X-XSS-Protection 过滤跨站脚本
 
 
 
X-XSS-Protection: 1; mode=block
 
 
Content-Security-Policy, X-Content-Security-Policy,X-WebKit-CSP 定义内容安全策略
 
 
 
X-WebKit-CSP: default-src 'self'
 
 
X-Content-Type-Options 唯一的取值是"",阻止IE在响应中嗅探定义的内容格式以外的其他MIME格式
 
 
 
X-Content-Type-Options: nosniff
 
 
X-Powered-By 指定支持web应用的技术
 
 
 
X-Powered-By: PHP/5.4.0
 
 
X-UA-Compatible 推荐首选的渲染引擎来展示内容，通常向后兼容，也用于激活IE中内嵌chrome框架插件
<meta http-equiv="X-UA-Compatible" content="chrome=1" />
 
 
 
X-UA-Compatible: IE=EmulateIE7
 X-UA-Compatible: IE=edge
 X-UA-Compatible: Chrome=1
 
 
X-Content-Duration 提供音视频的持续时间，单位是秒，只有Gecko内核浏览器支持
 
 
 
X-Content-Duration: 42.666
 
 
Upgrade-Insecure-Requests 标识服务器是否可以处理HTTPS协议
 
 
 
Upgrade-Insecure-Requests: 1
 
 
X-Request-ID,X-Correlation-ID 标识一个客户端和服务端的请求
 
 
 
X-Request-ID: f058ebd6-02f7-4d3f-942e-904344e8cde5
 
 
像这种条目信息最佳的展示形式肯定是表格，但是markdown格式渲染出来的表格，在电脑上勉强可以看，手机根本无法阅读，主要是因为每个条目信息内容长度不一致，所以写的时候就没有使用表格，我在github上上传一个excel版本的http头字段的说明，查看起来比较清晰，本人有时查看某些头字段值时，都是用excel版本的，你可以点这里下载。
 
这些条目解释的来源是维基百科，本人只是简单翻译，方便快速查看，如果想了解具体条目解释，可以查看原文中对应字段的引用，原文地址在这里
 
做好前端开发必须对HTTP的相关知识有所了解，所以我创建了一个专题前端必备HTTP技能专门收集前端相关的HTTP知识，欢迎关注，投稿。
 


 作者：留七七
 链接：https://www.jianshu.com/p/6e86903d74f7
 來源：简书
 简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。
 
转自：https://www.jianshu.com/p/6e86903d74f7
 
 
 
点击打开链接
 
 

1.背景介绍
 
作为一个Web开发人员，日常中与我们开发相关的，就是Chrome的开发者工具。
 
今天就是要简要说说Chrome的开发者工具中Network部分。
 
Network标签页对于分析网站请求的网络情况、查看某一请求的请求头和响
 
应头还有响应内容很有用，特别是在查看Ajax类请求的时候，非常有帮助。
 
2.知识剖析
 
1.Network中的信息
 
如果能多了解一些chrome开发者工具调试技巧/功能对于平时开发很与帮助，
 
在实际项目中多使用这些功能，提升自己的工作效率。下面我们来看chrome开发者工
 
具Network面板功能
 
1、Controls控制Network的外观和功能。
 
2、Filters控制Requests Table具体显示哪些内容。
 
3、Overview显示获取到资源的时间轴信息。
 
4、Requests Table按资源获取的前后顺序显示所有获取到的资源信息，点击资源名可以查看该资源的详细信息。
 
5、Summary显示总的请求数、数据传输量、加载时间信息。
 
network面板可以记录页面上的网络请求的详情信息，从发起网页页面请求Request后分析
 
HTTP请求后得到的各个请求资源信息（包括状态、资源类型、大小、所用时间、Request和Response等），可以根据这个进行网络性能优化。
 
下面我们主要讲Requests Table这一块的内容，header中的信息就在这一块。
 
名词解释
 
Name：资源名称，点击名称可以查看资源的详情情况，包括Headers、Preview、Response、Cookies、Timing
 
Status(&Text)：针对该请求服务器返回的状态码及描述该状态码的简短信息
 
Type:该资源的类型
 
Size:资源的大小
 
Time: Time就是从请求开始到接到最后一个字节所经历的时间；而Latency为请
 
求开始到接收第一个字节所经历的时间。此处的请求开始指的是该请求的状态从stalled（阻塞）状态开始。
 
Timeline（waterfall）:该列呈现出了每个请求从阻塞状态到完成请求所经历的阶段，和整个页面从加载到完成过程中其中
 
资源的加载流。
 
Initator:初始化该请求的对象或进程，有以下几种情况
 
Parser： 请求由Chrome的HTML解析器时发起的。
 
Redirect：请求是由HTTP页面重定向发起的。
 
Script：请求是由Script脚本发起的。
 
Other：请求是由其他进程发起的，比如用户点击一个链接跳转到另一个页面或者在地址栏输入URL地址。
 
headers中的信息
 
General:常规信息
 
1、Request URL:资源的请求url
 
2、Request Method:HTTP方法
 
3、Status Code:响应状态码
 
200：(状态码) OK
 
301：资源（网页等）被永久转移到其它URL
 
401：访问资源的权限不够。
 
403：没有权限访问资源。
 
404：需要访问的资源不存在。
 
405：需要访问的资源被禁止。
 
500 -内部服务器错误
 
更多关于这方面的知识可以参见相关小课堂
 
4、Remote Address：请求的远程地址
 
5、Referrer Policy：
 
在页面引入图片、JS等资源，或者从一个页面跳到另一个页面，都会产生新的HTTP请求，浏览器一般都会给这些请求头加上表示来源的Referrer字段。
 
新的Referrer Policy规定了五种Referrer策略：No Referrer、No Referrer When Downgrade、Origin Only、Origin When Cross-origin、和Unsafe URL。
 
No Referrer：任何情况下都不发送Referrer信息
 
No Referrer When Downgrade：仅当发生协议降级（如HTTPS页面引入HTTP资源，从HTTPS页面跳到HTTP等）时不发送Referrer信息。这个规则是现在大部分浏览器默认所采用的
 
Origin Only：发送只包含host部分的Referrer。启用这个规则，无论是否发生协议降级，无论是本站链接还是站外链接，都会发送Referrer信息，但是只包含协议+ host部分（不包含具体的路径及参数等信息）
 
Origin When Cross-origin：仅在发生跨域访问时发送只包含host的Referrer，同域下还是完整的。它与Origin Only的区别是多判断了是否Cross-origin。需要注意的是协议、域名和端口都一致，才会被浏览器认为是同域
 
Unsafe URL：无论是否发生协议降级，无论是本站链接还是站外链接，统统都发送Referrer信息。正如其名，这是最宽松而最不安全的策略
 
Response Headers:
 
字段
 
说明
 
Cache-Control
 
告诉浏览器或者其他客户，什么环境可以安全地缓存文档
 
Connection
 
当client和server通信时对于长链接如何进行处理
 
Content-Encoding
 
数据在传输过程中所使用的压缩编码方式
 
Content-Type
 
数据的类型
 
Date
 
数据从服务器发送的时间
 
Expires
 
应该在什么时候认为文档已经过期，从而不再缓存它？
 
Server
 
服务器名字。Servlet一般不设置这个值，而是由Web服务器自己设置
 
Set-Cookie
 
设置和页面关联的cookie
 
Transfer-Encoding
 
数据传输的方式
 
Request Headers:
 
字段
 
说明
 
Accept
 
表示浏览器支持的MIME类型
 
Accept-Encoding
 
浏览器支持的压缩类型
 
Accept-Language
 
浏览器支持的语言类型，并且优先支持靠前的语言类型
 
Cache-Control
 
指定请求和响应遵循的缓存机制
 
Connection
 
当浏览器与服务器通信时对于长连接如何进行处理：close/keep-alive
 
Cookie
 
向服务器返回cookie，这些cookie是之前服务器发给浏览器的
 
Host
 
请求的服务器URL
 
Referer
 
该页面的来源URL
 
User-Agent
 
用户客户端的一些必要信息
 
http协议报头详解
 
3.常见问题
 
使用post发送请求时如何设置content-type的值
 
4.解决方案
 
协议规定POST提交的数据必须放在消息主体（entity-body）中，但协议并没有规定数据必须使用什么编码方式。实际上，开发者完全可以自己决定消息主体的格式，只要最后发送的HTTP请求满足上面的格式就可以。
 
但是，数据发送出去，还要服务端解析成功才有意义。一般服务端语言如php、python等，以及它们的framework，都内置了自动解析常见数据格式的功能。服务端通常是根据请求头（headers）中的Content-Type
 
字段来获知请求中的消息主体是用何种方式编码，再对主体进行解析。所以说到POST提交数据方案，包含了Content-Type和消息主体编码方式两部分。
 
1. application/x-www-form-urlencoded最常见的POST提交格式，使用这个编码格式post的数据会以键值对的方式提交。
 
2. multipart/form-data通常上传图片等文件会使用这种编码格式提交。
 
3. application/json提交JSON格式的数据。
 
4. text/plain窗体数据以纯文本形式进行编码，其中不含任何控件或格式字符。
 
headers: {'Content-Type': 'application/x-www-form-urlencoded'}
 
当action为get时候，浏览器用x-www-form-urlencoded的编码方式把form数据转换成一个字串（name1=value1&name2=value2...），然后把这个字串append到url后面，用?分割，加载这个新的url。
 
当action为post时候，浏览器把form数据封装到http body中，然后发送到server。 如果没有type=file的控件，用默认的application/x-www-form-urlencoded就可以了。 但是如果有type=file的话，就要用到multipart/form-data了。浏览器会把整个表单以控件为单位分割，并为每个部分加上Content-Disposition(form-data或者file),Content-Type(默认为text/plain),name(控件name)等信息，并加上分割符(boundary)。
 
5.扩展思考
 
除了已经提到过的，content-type还有那些类型
 
HTTP Content-type对照表
 
6.参考文献
 
参考一：Referrer Policy介绍
 
参考二：Network面板
 
参考三：http协议报头详解
 



 转自：https://www.jianshu.com/p/ba719cf7269e