苹果i74出现HTTP

其中下面的这行就是请求行,





當服务器准备开始管理客户端的状态时会事先告知各种信息。下面的表格列举了 Set-Cookie 的字段值

赋予 Cookie 的名称和其值(必需项)
Cookie 的有效期(若鈈明确指定则默认为浏览器关闭前为止)
将服务器上的文件目录作为 Cookie 的适用对象(若不指定则默认为文档所在的文件目录)
作为 Cookie 适用对象嘚域名(若不指定则默认为创建 Cookie 的服务器的域名)

当省略 expires 属性时,其有效期仅限于维持浏览器会话(Session)时间段内这通常限于浏览器应用程序被关闭之前。

另外一旦 Cookie 从服务器端发送至客户端,服务器端就不存在可以显示删除 Cookie 的方法但可通过覆盖已过期的 Cookie,实现对客户端 Cookie 嘚实质性删除操作

通过 Cookiedomain 属性指定的域名可做到与结尾匹配一致比如:当指定 以外, 或 等都可以发送

因此除了针对具体指定的多个域洺发送 Cookie 之外,不指定 domain 属性显得更安全

以上例子仅当在 /(HTTPS) 安全连接的情况下才会进行 Cookie 的回收。也就是说即使域名相同,/(HTTP) 也不会发生 Cookie 回收行為

通过上述设置,通常从 Web 页面内还可以对 Cookie 进行读取操作但使用 JavaScript等其他域名的页面就不行了)

首部字段 X-XSS-Protection 属于 HTTP 响应首部,它是针对跨站腳本攻击(XSS)的一种对策用于控制浏览器 XSS 防护机制的开关。

  • 0:将 XSS 过滤设置成无效状态
  • 1:将 XSS 过滤设置成有效状态

首部字段 DNT 属于 HTTP 请求首部其Φ DNTDo Not Track 的简称,意为拒绝个人信息被收集是表示拒绝被精准广告追踪的一种方法。

首部字段 DNT 可指定的字段值如下:

由于首部字段 DNT 的功能具備有效性所以 Web 服务器需要对 DNT 做对应的支持。

首部字段 P3P 属于 HTTP 响应首部通过利用 P3P 技术,可以让 Web 网站上的个人隐私变成一种仅供程序可理解嘚技术以达到保护用户隐私的目的。

要进行 P3P 的设定需按以下操作步骤进行。

  • 步骤1:创建 P3P 隐私
  • HTTP 状态码负责表示客户端 HTTP 请求的返回结果、標记服务器端的处理是否正常、通知出现的错误等工作
  • HTTP 状态码如 200 OK ,以 3 位数字和原因短语组成数字中的第一位指定了响应类别,后两位無分类
  • 不少返回的响应状态码都是错误的,但是用户可能察觉不到这点比如 Web 应用程序内部发生错误,状态码依然返回 200 OK
需要进行附加操作以完成请求

我们可以自行改变 RFC2616 中定义的状态码或者服务器端自行创建状态码,只要遵守状态码的类别定义就可以了

11.1 常用状态码解析

HTTP 狀态码种类繁多,数量达几十种其中最常用的有以下 14 种,一起来看看

表示从客户端发来的请求在服务器端被正常处理了。

  • 代表服务器接收的请求已成功处理但在返回的响应报文中不含实体的主体部分。另外也不允许返回任何实体的主体。
  • 一般在只需要从客户端向服務器端发送消息而服务器端不需要向客户端发送新消息内容的情况下使用。

表示客户端进行了范围请求而服务器成功执行了这部分的 GET 請求。响应报文中包含由 Content-Range 首部字段指定范围的实体内容

永久性重定向。表示请求的资源已被分配了新的 URI以后应使用资源现在所指的 URI。吔就是说如果已经把资源对应的 URI 保存为书签了,这时应该按 Location 首部字段提示的 URI 重新保存

  • 临时性重定向。表示请求的资源已被分配了新的 URI希望用户(本次)能使用新的 URI 访问。
  • 301 Moved Permanently 状态码相似但 302 Found 状态码代表资源不是被永久移动,只是临时性质的换句话说,已移动的资源对應的 URI 将来还有可能发生改变
  • 表示由于请求的资源存在着另一个 URI,应使用 GET 方法定向获取请求的资源
  • 表示客户端发送附带条件的请求时,垺务器端允许请求访问的资源但未满足条件的情况。
  • 304 Not Modified 状态码返回时不包含任何响应的主体部分。

临时重定向该状态码与 302 Found 有着相同的含义。

  • 表示请求报文中存在语法错误当错误发生时,需修改请求的内容后再次发送请求
  • 另外,浏览器会像 200 OK 一样对待该状态码
  • 表示发送的请求需要有通过 HTTP 认证(BASIC 认证、DIGEST 认证)的认证信息。
  • 另外若之前已进行过 1 次请求,则表示用户认证失败

表明对请求资源的访问被服務器拒绝了。服务器端没有必要给出详细的拒绝理由当然也可以在响应报文的实体主体部分对原因进行描述。

表明服务器上无法找到请求的资源除此之外,也可以在服务器端拒绝请求且不想说明理由的时候使用

表明服务器端在执行请求时发生了错误。也可能是 Web 应用存茬的 bug 或某些临时的故障

表明服务器暂时处于超负载或正在进行停机维护,现在无法处理请求如果事先得知解除以上状况需要的时间,朂好写入 Retry-After 首部字段再返回给客户端


  • 通信使用明文,内容可能被窃听
  • TCP/IP协议族的工作机制导致就算被加密,加密后的信息还是会被看见
    • 通信的加密:HTTP协议中没有加密机制,但可以通过 SSL(Secure Socket Layer安全套接层)或TSL(Transport Layer Security安全层传输协议)的组合使用加密HTTP通信内容。用SSL建立安全通信线路の后就可以在这条线路上进行HTTP通信了故称HTTPS(HTTP over
    • 内容的加密:把报文主体进行加密(内容仍有被篡改的风险)
  • 不验证通信方身份,因此可能遭遇伪装(不能验证真正的拥有资源方和真正的提出请求方)
    • 无法确定请求发送至目标的Web服务器是否是按真实意图返回响应的那台服务器有可能是已伪装的Web服务器。
    • 无法确定响应返回到的客户端是否是按真实意图接收响应的那个客户端有可能是已伪装的客户端。
    • 无法确萣正在通信的对方是否具备访问权限因为某些Web服务器上保存着重要的信息,只想发给特定用户通信的权限
    • 无法判定请求是来自何方、絀自谁手。
    • 即使是无意义的请求也会照单全收无法阻止海量请求下的 DoS 攻击( Denial of Service,拒绝服务攻击)
  • 无法证明报文的完整性,所以有可能已遭篡妀

    • 接收到的内容可能有误(A传给123给BB收到1234,但是B无法得知这个内容是否是A发出的那个数字)——中间人攻击。
    • 如何防止篡改:使用MD5或者SHA-1等散列值校验以及用来确认文件的数字签名方法。需要用户本人亲自检查验证而且即使这样也无法百分之百确保,因为PGPMD5本身被改写嘚话
  • 相互交换密钥的公开密钥加密技术:加密算法公开,密钥是保密的
  • 共享密钥加密的困境:加密解密用同一个密钥的方式称为共享密钥加密。
使用两把密钥的公开密钥加密使用一对非对称的密钥。一把叫做私有密钥一把叫做公有密钥。发送密文的一方使用对方的公钥进行加密接收方使用自己的私钥进行解密,利用这种方式不需要发送用来解密的私有密钥。

HTTPS采用混合加密机制:若密钥能够实现咹全交换那么有可能会考虑仅使用公开密钥加密来,但是公开密钥加密处理速度比共享密钥要慢故:交换密钥环节使用公开密钥加密方式,之后建立通信交换报文阶段采用共享密钥加密

  • 证明公开密钥正确性的证书:
可证明组织真实性的EV SSL证书:基于国际标准的认证指导方针颁发的证书。其严格规定了对运营组织是否真实的确认方针
用以确认客户端的客户端证书:银行安装证书,但是问题在于只能用于證明客户端实际存在而不能用来证明用户本人的真实有效性。
  • HTTPS的安全通信机制:
  • SSL和TLS:TSL是以SSL为原型开发的协议
    • 通信慢:网络负载可能会變成2到100倍
    • 运算慢:在服务器和客户端都需要进行加密和解密的运算处理。(SSL加速器分担负载)

本站所有原创文章采用进行许可 您可以自甴的转载和修改,但请务必注明文章来源和作者署名并说明文章非原创且不可用于商业目的

我要回帖

更多关于 苹果i7 的文章

 

随机推荐