HTTP状态码、响应头、请求头

、状态码中文

100:“继续”，

101:“交换协议”，

200：“好的”，

201:“已创建”，

202:“接受”，

203:“非权威信息”，

204:“无内容”，

205:“重置内容”，

206:“部分内容”，

300:“多选”，

301:“永久移动”，

302:“找到”，

303:“见其他”，

304:“未修改”，

305:“使用代理”，

307:“临时重定向”，

400:“错误请求”，

401:“未授权”，

402:“需要支付”，

403:“禁止”，

404:“未找到”，

405:“方法不允许”，

406:“不可接受”，

407:“需要代理验证”，

408:“请求超时”，

409:“冲突”，

410:“消失”，

411:“长度要求”，

412:“前置失败”，

413:“请求实体太大”，

414:“请求URI太长”，

415:“不支持的媒体类型”，

416:“请求的范围不可满足”，

417:“期望失败”，

422:“不可处理实体”，

500:“内部服务器错误”，

501:“未实现”，

502:“坏网关”，

503:“服务不可用”，

504:“网关超时”，

505:“不支持HTTP版本”

二、状态码英文

108:"Continue"
191:"Switching Protocols"208OK
201:"Created"202:"Accepted"
203:"Non-Authoritative Information"
284:"No Content"
205"Reset Content"
206"Partial Content"398:"Multiple Choice"
301:"Moved Permanently"
392"Found"
303:"See Other"
384:"Not Modified",
305:"Use Proxy"
307:"Temporary Redirect"
408:"Bad Request"401:"Unauthorized"
402:"Payment Required"
403:"Forbidden"
484:"Not Found"
405:"Method Not Allowed"
486:"Not Acceptable"
497:"Proxy Authentication Required",
408:"Request Timeout"
409:"Conflict"
410:"Gone"
411:"Length Required".
412:"precondition Failed"
413:"Request Entity Too Large",
414:Request-URI Too Long",
415"Unsupported edia Type".
416"Requested Range Not Satisfiable"
417Expectation Failed"
422:Unprocessable Entity"500"Internal Server Error"
501:"Not Implemented"
502"Bad Gateway"
503:Service Unavailable".
504:Gateway Timeout"
505:"HTTP Version Not Supported"

三、HTTP Responses Header 响应头

Accept-Ranges  表明服务器是否支持指定范围请求及哪种类型的分段请求     Accept-Ranges:bytes
Age     从原始服务器到代理缓存形成的估算时间（以秒计，非负）Age:12
Allow  对某网络资源的有效的请求行为，不允许则返回405  Allow:GET, HEAD
Cache-Control 告诉所有的缓存机制是否可以缓存及哪种类型   Cache-Control:no-cache
Content-Encodingweb服务器支持的返回内容压缩编码类型。 Content-Encoding:

Content-Language 响应体的语言Content-Language:en,zh
Content-Length 响应体的长度Content-Length: 348
Content-Location  请求资源可替代的备用的另一地址 Content-Location:/index.html
Content-MD5    返回资源的MD5校验值  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 2010 08:12:31 GMT
ETag  请求变量的实体标签的当前值   ETag:“737060cd8c284d8af7ad3082f209582d”
Expires    响应过期的日期和时间    Expires: Thu, 01 Dec2010 16:00:00 GMT
Last-Modified     请求资源的最后修改时间    Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT
Location  用来重定向接收方到非请求URL的位置来完成请求或标识新的资源    Location:http://www.zcmhi.com/archives/94.html
Pragma     包括实现特定的指令，它可应用到响应链上的任何接收方    Pragma:no-cache
Proxy-Authenticate   它指出认证方案和可应用到代理的该URL上的参数        Proxy-Authenticate:Basic
refresh     应用于重定向或一个新的资源被创造，在5秒之后重定向（由网景提出，被大部分浏览器支持）Refresh: 5;url=http://www.zcmhi.com/archives/94.html
Retry-After   如果实体暂时不可取，通知客户端在指定时间之后再次尝试   Retry-After:120
Server  web服务器软件名称 Server: Apache/1.3.27(Unix) (Red-Hat/Linux)
Set-Cookie    设置HttpbCookie   Set-Cookie:UserID=JohnDoe; Max-Age=3600; Version=1
Trailer  指出头域在分块传输编码的尾部存在  Trailer:Max-Forwards
Transfer-Encoding   文件传输编码  Transfer-Encoding:chunked
Vary  告诉下游代理是使用缓存响应还是从原始服务器请求   Vary:*
Via     告知代理客户端响应是通过哪里发送的  Via:1.0 fred, 1.1 nowhere.com (Apache/1.1)
Warning  警告实体可能存在的问题  Warning: 199 Miscellaneous warning
WWW-Authenticate  表明客户端请求实体应该使用的授权方案   WWW-Authenticate:Basic
Access-Control-Allow-Origin 跨域 *

四、HTTP Request Header 请求头

题

响应头是在服务器发送页面的HTML代码之前，从服务器发送到浏览器。这些头信息包含着关于下列内容的有用信息：服务器希望的通信方式，页面类型，以及诸如截止日期和内容类型这样的元数据。响应是获取Web应用的先关信息的绝佳来源，对于我们想通过它实现的特殊功能来说，尤其如此。

响应头是攻击者用于查找应用特有信息的地方。与你的Web服务器和平台相关的信息将会作为标准请求的一部分被泄露出去。

解决方案

正如3.3节中所提到的，你可以在请求头旁边找到响应头，也可以通过代理来找到头信息，比如WebScarb。我们将利用这项任务来向你介绍TamperData,它是一个方便的工具，可以用在这项任务和其他几项任务中。

按照2.2节，安装TamperData。它的安装方法与大多数附加组件相同。

从“工具”菜单中打开TamperData，然后浏览到某个页面。在TamperData窗口中，你会发现它列举出了访问过的页面，这与WebScarab和FireBug是一样的。单击某个页面，就会显示出请求头和响应头，如图3-12所示。

讨论

响应头和响应本身之间存在着差别。响应头描述响应，它们是元数据。例如，响应头通常会包含以下内容：

状态（Status）

内容类型（Content-Type）

内容编码（Content-Encoding）

内容长度（Content-Length）

截止日期（Expire）

追后修改时间（Last-Modified）

多年来，响应头有所演化，因此，最初的规范（可以从http:///http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html访问）只对其中某些项（比如状态）而言是正确的。

另外，有些响应头会显示。服务器软件以及响应发出的日期和时间。如果你允许Internet上的每个人看到你正在使用的服务器和平台，那么现在就应该确保你安装了最新的补丁，并阻止了一切已知的漏洞。

请特别注意Content-Type头信息。大多数时间它只不过是像“text/html;charset=UFT-8”这样的内容，表示正常的HTML响应和编码。不过，它也可能引用外部应用或引起异常的浏览器行为，而这些异常之处正式攻击可能悄悄潜入的地方。

例如，已知有些旧版的PDF阅读器会执行通过查询字符串传入的JavaScript（详细情况请访问http://www.adobe.com/support/security/advisories/apsa07-01.html）。如果你的应用提供PDF，那么它是直接将Content-Type设置为applicant/pdf吗？又或者它设置了Content-Disposition头信息，要求用户先下载PDF，从而避免了任何JavaScript趁虚而入？

动态重定向是另一项危险的特性，因为它们可能会被攻击者用来将恶意网站的链接伪装成你的网站的链接，从而滥用了用户对你的网站的信任。作为链接，动态重定向通常具有如下形式：

http：//www.example.com/reirect.php?url=http://ha.ckers.org

可以看到，这些细节可能很难对付。如果你的应用使用某种特殊的头信息来处理文件上传、下载、重定向或任何其他事务，那么请确保研究了所有具体的安全防范措施，因为实际的危险要比这里所能列出的还要多。

新的响应头仍在不断地被开发出来。TrackBack、PingBack和RefBack是一种新的、通常被称为LinkBack的Web功能的相互竞争的标准。这些LinkBack提供了一种双向的链接功能。它们因为迎合了当前的博客热而备受欢迎。

例如，如果Fred从自己的博客链接到Wilma的博客，那么他们的博客托管服务可以使用某种标准进行通信，于是Wilma的博客将显示Fred链接到她的博客。HTTP头可帮助识别使用的是哪些标准，并传送链接信息。

搜索微信公众号：TestingStudio霍格沃兹的干货都很硬核

了提升浏览器加载页面资源的性能，对于js、css、图片等静态资源，web服务器往往会通过Cache-Control、ETag/If-None-Match、Last-Modified/If-Modified-Since、Pragma、Expires、Date、Age等头部来控制、管理、检测这类资源对缓存机制的使用情况。同时，为了使新版本的js、css等资源立即生效，一种比较通行的做法是为js、css这些文件名添加一个hash值。这样当js、css内容发生变化时，浏览器获取的是不同的js、css文件。在这种情况下，旧版本的index.html文件可能是这样的：

<!DOCTYPE html>
<html>
    <head>
        <meta charset=utf-8>
        <title>测试</title>
        <meta http-equiv=X-UA-Compatible content="IE=Edge">
        <meta name=viewport content="width=device-width,minimum-scale=1,maximum-scale=1">
        <link href=/static/css/main.4656e35c1e8d4345f5bf.css rel=stylesheet>
    </head>
    <style>
        html, body {
            width: 100%;
        }
    </style>
    <body>
        <div id=newMain></div>
        <script type=text/javascript src=/static/js/main-4656e35c1e8d4345f5bf.js></script>
    </body>
</html>

当项目的js、css内容发生了变化时，新版本的index.html文件内容变成这样的(js和css文件名携带了新的hash值1711528240049）：

<!DOCTYPE html>
<html>
    <head>
        <meta charset=utf-8>
        <title>测试</title>
        <meta http-equiv=X-UA-Compatible content="IE=Edge">
        <meta name=viewport content="width=device-width,minimum-scale=1,maximum-scale=1">
        <link href=/static/css/main.1711528240049.css rel=stylesheet>
    </head>
    <style>
        html, body {
            width: 100%;
        }
    </style>
    <body>
        <div id=newMain></div>
        <script type=text/javascript src=/static/js/main-1711528240049.js></script>
    </body>
</html>

因为index.html文件一般会设置为不缓存，这样用户每次访问首页时，都会从web服务器重新获取index.html，然后根据index.html中的资源文件是否变化，从而决定是否使用缓存的文件。这样既能让用户立即获取最新的js、css等静态资源文件，又能充分地使用缓存。index.html的响应头大概长这样：

但是为了保证系统的高可用，web后端往往由多个实例提供服务，用户请求会在多个服务实例间进行负载均衡。而系统升级过程中，会存在多个版本共存的现象。这时，如果用户从旧版本实例上获取了index.html文件，然后再去获取旧版本的js、css文件(main-4656e35c1e8d4345f5bf.js和main.4656e35c1e8d4345f5bf.css），但是请求却分发到了新版本服务实例上，这时因为新版本服务实例只有main-1711528240049.js和main.1711528240049.css文件，就会导致访问失败。反过来，如果从新版本实例上获取了index.html文件，在请求相应的js、css文件时，也可能被分发到旧版本实例上，也导致访问失败。

解决方法：

1）首先，改造一下index.html文件中引用js、css等静态资源的路径，添加一个版本号，如v1、v2，这样index.html文件对js、css的引用变为：

<link href=/static/v1/css/main.1711528240049.css rel=stylesheet>
<script type=text/javascript src=/static/v1/js/main-1711528240049.js></script>

2）使用灰度发布策略升级系统，具体步骤如下（假设系统包含A、B两个服务实例）

升级前(稳态），在应用网关（代理）上配置路由策略V1，该路由策略的功能为：匹配路径前缀/static/v1的请求负载均衡分发到A、B两个服务实例
将待升级的服务实例A从路由策略V1中摘除掉，这时用户请求只会发送给实例B
待实例A上所有进行中的请求都处理完后，就可以安全的停掉旧的服务，替换为新的服务，这时还不会有请求分发到实例A
待实例B测试功能正常后，在应用网关（代理）上新增一条路由策略V2，该路由策略的功能为：匹配路径前缀/static/v2的请求分发到服务实例A。这时，从服务实例A上获取的index.html文件引发的后续js、css请求，都会分发到服务实例A，从服务实例B上获取的index.html文件引发的后续js、css请求，都会分发到服务实例B
继续将实例B从路由策略V1中摘掉，然后升级实例B，将实例B添加到路由策略V2中
所有的流量都切换到了路由策略V2中，下线路由策略V1。完成整个升级过程，实现了前端的无损升级

作者：movee
链接：https://juejin.cn/post/7353069220827856946

在线咨询

上一篇：什么是APP封装？APP封装如何实现？
下一篇：Canvas之鼠标滑动特效

您的项目需求

*请认真填写需求信息，我们会在24小时内与您取得联系。

整合营销服务商

HTTP状态码、响应头、请求头

您的项目需求