博客园_Franky

IE6 与 GZIP, BUG汇总

2012-04-28T07:28:00Z

bug1描述:

IE6部分版本,某些情况下,开启gzip的资源,会不渲染或不执行(如果是.js的话.)

会引发此bug的条件:

1. 首先,必须由a页跳转到b页面 : 即 a页面有 location.href = b页面.(点链接,form post,replace, assign等方式都会导致问题,包括target=_blank弹窗的情况)

2. b页面自身,或使用动态创建脚本(硬编码script src=xxx 也存在此问题) 的响应头中包含下面情况:

cache-control 包含下列伪指令:

(1) no-store

(2) no-cache + 其他与缓存新鲜度检验有关头共存时, 如 max-age=xxx (xxx无所谓.0 或3000都会触发,) 或 no-cache + must-revalidate 甚至是,no-cache, pre-check=0等情况..

(3) no-cache独立存在时,体现为一种不稳定情况.可能会触发.但也不是100%.仅仅是偶尔...

ps: 本bug ,与 http1.0 头域 : Pragma : no-cache ,无关. 也于是否chunked输出无关.

更神奇的是,一但,开启gzip, 则 i6会无视ETag .(ETAG,bug没有被我独立列出来.因为它的严重性并不太高..) 不会尝试2次握手.完全放弃使用本地缓存....也就是说,ie6发起请求时,不会带有 if-none-match头...

Last-Modified则无此问题.

但是要注意的是: IE6会开启gzip的情况下, 在if-Modified-Since 值中加入length = xxxx .字样. 我不确定所有的web server 在检测该值是检验相等性，还是检测包含性.尤其是大家用nodejs写一个轻量级web server的时候.一定要注意这个问题

.务必使用 headers['if-Modified-Since']indexOf(缓存日期) > -1 的逻辑来做.

如图:

IE7+ 则无此问题..

解决办法:

1. 放弃gzip.

2. 放弃cache-control 中的 no-cache,no-store头域. 比如单独使用max-age=0.并对不支持http1.1的老浏览器配合Expires = 一个过期时间.

ps :

1.与bug1类似的情况还有ajax , 或动态发起的jsonp 等请求. 当某个页面有这种情景，且被请求资源开启gzip , cache-control有前面提到的那些配置.那么同一个资源(即使querystring有不同),第二次对其发起请求,就可能导致ajax readyState==4的情况不被出发,或jsonp的脚本不被执行. 解决办法同上.

2.类似的,如果多个iframe 自身就有gzip,则也会引发问题.即不渲染，甚至可能会定位到404(抓包一切正常).

msdn上的说法:

To work around this problem, you can do either of the following:

If you use a Cache-Control: no-cache HTTP header to prevent the files from caching, remove that header. In some situations, if you substitute an Expires HTTP header, you do not trigger the problem.

-or-

Do not enable HTTP compression for the script files.

显然,微软给了我们两条路,去掉no-cache头,或者使用Expires指定过期时间，强制使其过期代替no-cache, 或者别压缩. 而pre-check=0.显然可以代替Expires做到这件事.

一个常见的误区是,有些朋友收借助 cache-control ,IE定义的扩展指令来解决这个问题.参考下面的描述:

扩展指令 中一个常见的东西是 none-check post-check 和 pre-check. 这玩意是IE5被加入的. 所以如果响应头中有这几个扩展指令,那么IE就会认得他们, 我经常在一些为了解决 cache + gzip 命中ie6 JSONP 请求,导致脚本不执行bug的方案中见到这几个扩展指令，其目的是为了让IE放弃使用本地缓存. 我倒是觉得,对IE6放弃使用gzip,是更合理的做法. 当然缺点也很明显, 如果是cdn部署静态资源.显然这样做会很困难.

关于这几个扩展指令的, 参考msdn 的描述:http://msdn.microsoft.com/en-us/library/ms533020%28VS.85%29.aspx#Use_Cache-Control_Extensions

post-check
- Defines an interval in seconds after which an entity must be checked for freshness. The check may happen after the user is shown the resource but ensures that on the next roundtrip the cached copy will be up-to-date.
pre-check
- Defines an interval in seconds after which an entity must be checked for freshness prior to showing the user the resource.

一张图:

简单来说, 就是控制IE,如何使用本地缓存 ,如果缓存时间,超过post-check的值,就要保证下一次请求该资源,去要验证过的新鲜的.而pre-check则是超过了，就马上给个新的. no-check就无需解释了..

但这个方法本质上是无法绕过这个bug的... 所以根本原因还是 ,去掉no-cache,no-store. 或放弃压缩.

bug2 描述:

当一个页面,有多个iframe , 而每个iframe 都引入 a.js 时, 如果a.js 开启gzip ,且有缓存,比如 Expire= xxx, Control-Cache: max-age= xxxx 的情况下
那么这个a.js就可能在某次不被执行. （请注意这个问题和之前gzip第一个bug情形不同.上一个是no-cache出现bug. 而这个,已经和http,cache无直接关系了.当然,如果你配置了no-cache,那么这个bug是肯定会触发的,具体原因，请看解决方案中的第三条.所以某种角度来说，这个问题,可能和第一个bug描述,仍然有间接关系.只不过,我个人测试情况是,20个iframe,如果请求的js都是不同的url,那么即使配置no-cache,也没有触发我们的bug2,但是这回带来bug3.我们会在bu3中描述它. 但如果配置no-cache,多个iframe中请求相同的url的js,那么bug2就仍然会被触发.这是因为我们预加载已经失去意义.）

分析: 大概是高并发请求时,IE共享以某个url为标签的资源的状态时,在某种特定情况下,把n个独立请求的相同资源的状态给共享了,比如把某脚本的待执行状态标为已执行过. 但是为什么,只有gzip的资源才会发生.就不得而知(更重要的是,并不直接与资源是否具备缓存能力有直接关系.). 一切都是黑盒推测.所以也做不得准...

ps: iframe 下引入多个脚本,是可以并行加载,且无视http连接数限制的。

如果a.js在 iframe中是document.write,或appendChild等动态方式.那么bug发生几率会都陡升.

如果a.js在同一个页面被引入多次,则不会有任何问题. 原因是,IE6+有一个优化策略.当同一个页面多次引入一个相同的资源时,后续资源不会走网络模块,也就是说，不会发起请求.而直接从以资源url为索引的内存中直接使用该资源. 所以就不会发生问题.

IE7+,在前面多个iframe中引入同一个.js时,会有类似同一页面多次引入同一.js时同样的优化策略.不发起请求. 不考虑IE7是否有gzip bug. 即使有,也会因为,没有走网络模块而绕过了gzip bug.

解决方案 :
1. 放弃缓存，比如去掉max-age= xxx,去掉Expires ,或让他们为一个过期值. 或添加 no-cache,no-store.(此项是不被推荐的，因为它只是降低bug触发几率)
2. 放弃gzip .
3. 让IE6,在top页预加载一次.js资源. 这样, 在多个iframe中. 引入的.js,会直接走cache.在后续iframe请求.js 都走cache的情况下会绕过这个bug. (如果用户是ctrl+ f5,强制刷新.都不走cache,当iframe很多，资源加载很多次时bug触发概率也会陡升,也就是说,预加载资源只能解决常规问题.一些特殊情况仍然无法绕过. 当然,普通的f5是ok的因为普通的f5,会触发IE6的优化策略.这时候其行为会像前面提到的IE7+那样,对多个相同的资源,只走一次网络模块.所以就绕过了bug,而ctrl+f5则有几个就走几次网络模块.. 更重要的是，如果想让预加载产生效果,我们就必须给资源开启缓存. 如果资源不能被缓存,则预加载就失去了意义.这是要注意的情况.)

我个人建议采用第三种. 在top页预加载一次.

为了不浪费客户端性能, 我建议使用下面的代码来进行预加载.

这个代码的作用是,只有IE6进行预加载,而且借助type="text/c" 让IE6只加载a.js 而不执行它....

bug3 描述

如果你的浏览器是IE6 SP2-(SP3已经修正这个问题,此问题与iframe与否，无直接关系,BUG1,BUG2,的场景，都可能触发BUG3).当你引入多个不同url的xxx.js时, 第一次后, f5刷新浏览器.那么ie就会忘记你的js的编码. 比如我们在xxx.js中输出了一些汉字.而我们引入该js,编码要么是GBxxxx或GBk,要么是utf - xx. 那么就会出现乱码，甚至是因为乱码导致js解析失败.抛出异常. 而首次访问,或ctrl+f5强制刷新,则无此问题...

解决办法:

1. 不要有no-cahce,no-store,等等.

2. 放弃gzip

3. ...... 好吧,真的没有3了..

总结:

这真是一个异常艰难的总结，但我们总要面对这些让人吐血的问题,不是么?

bug触发的条件，环境很复杂,绝大多数情况下，我们可以认为是某个资源多次被加载则触发的可能性会陡升

假设, 你是用jsonp,等方式加载数据.又需要开启gzip ,而该数据总是动态的，(即我们不希望它被任何中间环节缓存).而且，你又要保证这玩意,不会在多个iframe中存在.而仅仅服务于某一个特定页面的话, 那就记得别用Cache-Control:no-cache,no-store ,而改用Expires = 过期时间 + max-age=0 来搞定.

假设我们期待某些资源总是被缓存的. 又不得不开启gzip ,而资源,又总是出现在一些iframe中, 那么记得.在top页, 预加载他们是个不错的选择.

否则,对ie6 放弃 gzip 吧,兄弟们. gzip对于ie6来说,真是万恶之源啊...(nginx 针对ie6,不开启gzip,很简单,只要一行短短的配置指令即可.如果需要,请查文档.nginx真的很贴心.可以方便的针对某一种ua,开启或关闭某些东东.)

最后不得不提的是.我之前一再说过一个词，就是不渲染. 那么解释下,不渲染是指,如果资源是一个html. 那么这个html里的任何东西,都不会渲染. 内部资源也不会加载. IE6,SP2-遇到编码问题,也是一样的....

好吧. 最后 IE6 SUCKS !!! ....

本文链接

ES3和ES5中函数调用(function call) 的浏览器实现差异.

2011-12-02T03:34:00Z

正美今天扔出来的类似下面的代码:

参考代码:

var o = {
test: function () {alert('origin')}
};
o.test(o.test = function(){ alert('changed'); });

这段代码,我们直觉，觉得打印 origin 才是合理的. 至少我个人是这样认为的.

但是.Chrome17-, IE8- 都会打印changed . 而 Firefox0.8+，Safai3+, Opera9.2+,IE9+ 则都打印origin.

出现这个问题的根源,我们通过翻看 ES3和ES5,可以找到原因. 原来ES3和ES5,在此处是有冲突的. 道格拉斯认为ES3是不合理的. 所以更改了这里的逻辑.

ES3:

Function Calls
The production CallExpression : MemberExpression Arguments is evaluated as follows:
1. Evaluate MemberExpression.
2. Evaluate Arguments, producing an internal list of argument values (see 11.2.4).
3. Call GetValue(Result(1)).

ES5:

11.2.3 Function Calls
The production CallExpression : MemberExpression Arguments is evaluated as follows:

1. Let ref be the result of evaluating MemberExpression.
2. Let func be GetValue(ref).
3. Let argList be the result of evaluating Arguments, producing an internal list of argument values (see 11.2.4).

可见ES5 对MemberExpression 也就是这里的函数名部分的表达式所获取的引用,进行getValue运算是早于对实参列表进行evalute的.

而ES3则恰恰相反.

那么我们从纵观历史的角度来看问题. 孰对孰错呢？

.Firefox4才开始真正的按照ES5标准来实现引擎.那么Firefox 3.6-的浏览器，就并没有遵守当时的ES3现行标准.

.Opera11.6开始比较完善的按照ES5实现.所以Opera11.5-的浏览器.同FF3.6-一样.并没有遵守ES3.

.Safari3-5 也是如此.在Safari5.11仍然对ES5支持度十分底下的前提下，居然始终不曾遵守过ES3.

.Chrome 从5开始部分支持ES5的API,并在版本11开始，比较完善的按照ES5实现. 但是一直到版本17.居然仍然是按照ES3的实现. 很明显是不对的.

那么对这里从历史角度来看，最好的居然是IE系列. IE系从9开始按照ES5实现jscript引擎。结果其表现在这一点上就十分完美. IE8-按照ES3实现.IE9+ 按ES5实现.

这一次,IE值得表扬!奖小红花一朵。

最后说说ES3的这处奇怪的设定.

对于new NewExpression

就完全没有这个问题.也与ES5是一致的.

即先 evalute newExpression,然后对其getValue, 然后才去 evalute Arguments

参考代码:

var cons = function () {this.name = 1;};
var obj = new cons(cons = function () {this.name = 2;});
alert(obj.name)

所有浏览器的实现都不会有差异，因为ES3,5之间没有差异.那为什么function call 会这样奇怪呢？我暂时还想不出当初这样设计的理由.....先记一下吧.

本文链接

你应该了解的一些web缓存相关的概念.

2011-11-23T05:14:00Z

说明:本帖主要针对各个环节的缓存代理,以及本地用户代理（浏览器）上的缓存策略.

ps:应舍瓦大大要求,从我的evernote里翻找出这篇和cache相关的东西. 难免有错漏指出,欢迎指正.

代理服务器简分类:(并不太全，仅当科普, 了解代理在web中的重要作用是有必要的.这里仅仅是简单介绍下.)

缓存角度分类:

(1) 缓存代理 : 根据某种约定,缓存曾经请求过的数据

(2) 常规代理 : 只转发请求的那一种.并不缓存数据的代理

控制方分类：

(1) 反向代理：(对于原始服务器来说,反向代理即是一个客户端)

a) 服务提供者主观使用,并控制.

b) 相对其他客户端来说,离原始服务器最近(主观上)

c) 转发请求,缓存,用于负载均衡.

d) 屏蔽其他客户端与原始服务器的直接联,避免原始服务器被直接攻击

e) CDN的应用(严格来说,CDN已经并非纯粹意义上的反向代理了.)

(2) 非反向代理: (非服务提供者所控制)

其他分类:

(1) 用户代理

a) 浏览器

b) 各类终端机

c) 搜索引擎爬虫.

(2) 透明代理

(3) 拦截代理

(4) http代理

(5) socket代理(UDP,FTP…etc)

缓存相关的约定,HTTP协议、相关概念

HTTP1.1协议:

继承自http1.0，在其基础上扩展或修改而产生. 比如1.0中Date标头,允许使用的RFC1036日期格式,的千年虫问题的修正.悲剧的是,有些明显的错误,无法矫正,比如一个著名的拼写错误. Referer 标头的拼写错误.一直沿用至今.因其,已经被广泛应用.在实际使用上，又无伤大雅,所以也就被继续将错就错了.
实体: 用于表示一个,请求或响应的消息中的一个资源,如post提交的表单内容,或请求服务器上的abc.jpg时,abc.jpg就代表一个实体.对于一个实体响应来说，除去响应标头外所剩余的部分,即是实体主体部分,比如abc.jpg的真实2进制数据.

标头(头域):

(1) 请求标头 : 在一个请求中使用的相关标头,用于添加附加信息,或对被请求服务器增加限制.

(2) 响应标头 : 用于添加相关响应的附加信息.

(3) 实体标头 : 提供实体相关的附加信息,如果修改时间,实体的大小等等.

(4) 常规标头 : (通用标头)在请求和响应中都可以使用的一些常规标头,如HTTP1.0所定义的Date.和 Pragma(是的,这并不是一个实体标头,它仅仅是试图与客户端,包括代理,进行协商,不要使用缓存的副本.).

补充:HTTP1.1的常规标头:

Date,Pragma,Cache-Control,Connection,Transfer-Encoding,Upgrade,Trailer,Via,Warning

缓存相关标头:

. Expires (实体标头,HTTP 1.0+)

一个GMT时间,试图告知客户端,在此日期内,可以信任并使用对应缓存中的副本,缺点是,一但客户端日期不准确.则可能导致失效.

.Pragma : no-cache(常规标头,http1.0+)

对Pragma定义的唯一的伪指令,同http1.1的Cache-Control : no-cache

.Last-Modified(实体标头,HTTP1.0+)

一个GMT时间,告知,被请求实体的最后修改时间.用于客户端校验其缓存副本是否仍然可以信任.与其相关的两个条件请求标头：

（1） If-Modified-Since：（此标头,仅对Get方法有意义）

如果实体在指定时间后,没有修改则返回一个304,否则返回一个常规的Get请求的响应(比如200). 另外,如果该标头的值是一个非法的值,那么也同样返回一个常规的Get请求的响应.

PS:用户代理发起 If-Modified-Since尝试握手的条件，可能会有不同,比如IE系,如果该实体第一次响应头中包含Cache-Control:no-cache.则 IE不会使用If-Modified-Since请求资源.而其他浏览器则会. 但是如果使用Cache-Control:no-store.则所有用户代理的表现一致.都不使用If-Modified-Since(因为no-store的语义十分强烈.不允许任何缓存,这个在后续有专门介绍.)

（2） If-Unmodified-Since:

如果实体在指定时间后,没有任何修改,那么就可以直接执行该请求使用方法的对应行为. 而如果有修改,则返回一个412 Precondition Failed状态码,并且抛弃该方法对应的行为操作(GET方法除外).

. Cache-Control : (常规标头,HTTP1.1)

.public:(仅为响应标头)

响应:告知任何途径的缓存者,可以无条件的缓存该响应.

.private(仅为响应标头)

响应:告知缓存者(据我所知,是指用户代理，常见浏览器的本地缓存.用户也是指,系统用户.但也许,不应排除,某些网关,可以识别每个终端用户的情况),只针对单个用户缓存响应. 且可以具体指定某个字段.如private –“username”,则响应头中，名为username的标头内容，不会被共享缓存.

.no-cache:

请求: 告知缓存者，必须原原本本的转发原始请求,并告知任何缓存者,别直接拿你缓存的副本,糊弄人.你需要去转发我的请求,并验证你的缓存(如果有的话).对应名词:端对端重载.

响应: 允许缓存者缓存副本.那么其实际价值是,总是强制缓存者,校验缓存的新鲜度.一旦确认新鲜,则可以使用缓存副本作为响应. no-cache,还可以指定某个包含字段,比如一个典型应用,no-cache=Set-Cookie. 这样做的结果,就是告知缓存者,对于Set-Cookie字段,你不要使用缓存内容.而是使用新滴.其他内容则可以使用缓存.

.no-store:

请求:告知,请求和响应都禁止被缓存.(也许是出于隐私考虑)

响应:同上.

.max-age:

请求:强制响应缓存者，根据该值,校验新鲜性.即与自身的Age值,与请求时间做比较.如果超出max-age值,则强制去服务器端验证.以确保返回一个新鲜的响应.其功能本质上与传统的Expires类似,但区别在于Expires是根据某个特定日期值做比较.一但缓存者自身的时间不准确.则结果可能就是错误的.而max-age,显然无此问题. Max-age的优先级也是高于Expires的.

响应:同上类似,只不过发出方不一样.

.max-stale:

请求:意思是,我允许缓存者，发送一个,过期不超过指定秒数的,陈旧的缓存.

响应:同上.

.must-revalidate(仅为响应标头)

响应:意思是,如果缓存过了新鲜期，则必须重新验证.而不是试图返回一个不在新鲜期的缓存.与no-cache的区别在于,no-cache,完全无视新鲜期的概念.总是强制重新验证.理论上,must-revalidate更节省流量,但相比no-cache,可能并不总是那么精准.因为即使缓存者，认为是新鲜的,也不能保证服务器端没有做过更新.如果缓存者是一个缓存代理服务器,如果其试图重新验证时，无法连接上原始服务器,则也不允许返回一个不新鲜的,缓存中的副本.而是必须返回一个504 Gateway timeout.

.proxy-revalidate(仅为响应标头)

响应:限制上与must-revalidate类似.区别在于受体的范围.proxy-revalidate,是要排除掉用户代理的缓存的.即，其规则并不应用于用户代理的本地缓存上.

.min-fresh(仅为请求标头)

请求:告知缓存者,如果当前时间加上min-fresh的值,超了该缓存的过期时间.则要给我一个新的.其实个人觉得,其功能上有点和max-age类似.但是更大的是语义上的区别.

.only-if-cached:(仅为请求标头)

请求:告知缓存者,我希望内容来自缓存，我并不关心被缓存响应,是否是新鲜的.

.s-maxage(仅为响应标头)

响应:与max-age的唯一区别是,s-maxage仅仅应用于共享缓存.而不引用于用户代理的本地缓存,等针对单用户的缓存. 另外,s-maxage的优先级要高于max-age.

.cache-extension (cache-extension是一个泛化的代称.它指所有自定义，或者说扩展的,指令,客户端和服务器端都可以自定义扩展Cache-Control相关的指令.) 那么,实际上我们可以这样 Cache-Control:max-age=300, custom-directive = xxx, public. 这样我们就定义了一个被统称为cache-extension的扩展指令.该指令如果对应的客户端或服务器端，不认识,就会忽略掉.

扩展指令 中一个常见的东西是 none-check post-check 和 pre-check. 这玩意是IE5被加入的. 所以如果响应头中有这几个扩展指令,那么IE就会认得他们, 我经常在一些为了解决 no-cache + gzip 命中ie6 JSONP 请求,导致脚本不执行bug的方案中见到这几个扩展指令，其目的是为了让IE放弃使用本地缓存. 我倒是觉得,对IE6放弃使用gzip,是更合理的做法. 当然缺点也很明显, 如果是cdn部署静态资源.显然这样做会很困难.

bug描述:

IE6,某些情况下,开启gzip的资源,会不渲染或不执行(如果是.js的话.)

会引发此bug的条件:

1. 首先,必须由a页面脚本导致跳转到b页面 : 即 a页面有 location.href = b页面.(点链接,form post,replace, assign等方式都会导致问题,包括target=_blank弹窗的情况)

2. b页面自身,或其使用动态创建脚本(硬编码script src=xxx 也会有此问题) 的响应头中包含下面情况:

cache-control 包含下列伪指令:

(1) no-store

(2) no-cache + 其他与缓存新鲜度检验有关头共存时, 如 max-age=xxx (xxx无所谓.0 或3000都会触发,) 或 no-cache + must-revalidate甚至是,no-cache, pre-check=0等情况..

(3) no-cache独立存在时,体现为一种不稳定情况.即当访问页面被cache时,可能会触发.但也不是100%.仅仅是偶尔...

遇到以上情况,页面可能会不渲染,而脚本可能会不执行.

ps: 本bug ,与 http1.0 头域 : Pragma : no-cache ,无关.

解决办法:

1. 放弃压缩.

2. 放弃cache-control 中的 no-cache,no-store头域. 比如单独使用max-age=0.并对不支持http1.0的老浏览器配合Expires = 一个过期时间.

关于这个bug的msdn的描述:

To work around this problem, you can do either of the following:

If you use a Cache-Control: no-cache HTTP header to prevent the files from caching, remove that header. In some situations, if you substitute an Expires HTTP header, you do not trigger the problem.

-or-

Do not enable HTTP compression for the script files.

关于这几个扩展指令的, 参考msdn 的描述:http://msdn.microsoft.com/en-us/library/ms533020%28VS.85%29.aspx#Use_Cache-Control_Extensions

post-check
- Defines an interval in seconds after which an entity must be checked for freshness. The check may happen after the user is shown the resource but ensures that on the next roundtrip the cached copy will be up-to-date.
pre-check
- Defines an interval in seconds after which an entity must be checked for freshness prior to showing the user the resource.

一张图:

.no-transform

请求:告知代理,不要更改媒体类型,比如jpg,被你改成png.

响应:同上.

.Etag :(实体标头，HTTP1.1)

通过[Mog95],( http://www.research.digital.com/wrl/publications/abstracts/95.4.html

遗憾的是，该地址，现在似乎访问不能.)生成一段可代表实体版本的字串.默认就是一段hash + 时间戳的形式.其实我们是可以使用自己的算法来生成Etag值.比如md5.

PS:Apache的默认Etag包含Inode,Mtime,Size三部分.而且Etag有强弱之分.比如一般的弱Etag,是以W/开头的,如:W/”abcde12”,这部分不是我们关注的焦点.因为弱Etag和强Etag的区别只在于算法.比如某种弱Etag关注的时间精度,为秒.而我们在项目中,最常见的做法是使用MD5.是一种忽略时间维度的,强Etag.为的是保证精确度.以及负载均衡设备的同步.除非我们的项目有特殊需求.但是往往我们可以根据需求,来调整算法.而不是沿用一些传统的弱Etag算法.

这东西,是要和客户端的两个请求标头配合使用的:

(1) If-Match:

语义:如果有匹配,或者值为”*”,才可以能去执行,请求所使用的方法,所对应的行为.

If-Match,可以看做是一个过滤器,主要应用于资源多版本共存的解决方案.比如服务器端对同一实体，有多个版本.那么客户端，即可按照指定版本来获取实体.

If-Match的值就是对应指定版本的Etag值.这个值可以是多选的.典型的应用场景是,客户端使用put方式请求服务器端,并带有多个If-Match的值.服务器端检查所有该实体的版本.找到匹配项,就立刻更新服务器端的对应版本.如果无一匹配,则发送一个412 Precondition Failed状态码.

(2) If-None-Match:

语义:如果有任何匹配,或值是”*”,并且原始服务器存在其请求的实体,则不允许执行该请求所使用放的对应行为,如果此时,该请求使用的get,或head方法.则返回一个304状态码.以及其他一些相关的缓存控制的标头.

与If-Match相反 .但它的典型应用,也是我们要关注的部分.支持http1.1的现代浏览器,以及web server,应用If-None-Match头用于,缓存新鲜度校验.典型应用场景就是,一但原始服务器的某个响应中包含Etag时,如果浏览器本地缓存了该实体.那么在第二次的常规的get或head请求时,就会自动带上 If-None-Match头.当原始服务器上该实体的版本对应的Etag值与之匹配时,则原始服务器会返回304状态码.然后浏览器认为本地缓存是新鲜的.则继续使用缓存的实体. 但,其实Etag的本意是版本管理.而并不是缓存有效性校验.这应该是一个衍生出来的使用方式. 而这种方式相比Last-Modified校验方式的好处是,如果我们消除时间戳部分,仅使用hash作为Etag值. 就可以方便做负载均衡同步.

.Age(响应标头,HTTP1.1)

Age标头,对于原始服务器来说,用于指明,当前资源被生成了多久,即存活期.而对于一个缓存代理服务器来说，它表示缓存副本,被缓存了多久.缓存代理服务器，必须生成Age头.其值以秒为单位.且可能为负值.

.Vary(响应标头,HTTP1.1)

Vary标头，用于列出一组响应标头,用于缓存者从其缓存副本中筛选合适的变体.举个例子来说,不同的请求方法,导致对同一资源的响应有区别.这就导致缓存者有多份缓存副本.那么Vary所列出的标头项,就是选择副本时的一个重要依据. 比如Vary:Accept-Language.那么如果新的请求中的Accept-Language标头的值,而原始请求(被缓存的那个)中并未包含与之匹配的Accept-Language的标头的话.那就必须放弃该副本.而是把请求转发到原始服务器.

另一个Vary的典型应用是,Vary:Accept-Encoding.这样做的意义在于,某些用户使用的浏览器,可能不支持一些特定的压缩算法.那么当这个用户途径的某个共享的缓存代理服务器,所缓存的使用了某种压缩算法的响应,就不能直接返回给该用户.如果服务器端,并没有配置这个标头,那就可能产生悲剧.即用户的浏览器无法解压缩返回的资源.导致各种异常状况的出现.

范围相关标头.以及缓存的意义.

请求标头:

.Range : 1000- | -1000 | 0 - Content-Length

Range头可以指定像服务器(并不一定总是原始服务器,比如一个缓存代理服务器)端获取范围内的数据,这种格式是很松散的,可以用”,”逗号分割范围的一种表达式.比如1-100,-1 这就表示要获取第一到100个字节,以及最后一个字节的部分.又或者 50-则表示50个字节之后的所有数据搭配可以很灵活.不过,当使用多个范围的Range标头时,假设范围都是合法的(不存在越界的情况,如果越界,则可能返回417 Requested Range Not Satisfiable状态码).则服务器响应时,会修改响应中的Content-Type标头为如下格式:

Content-Type : multipart/byteranges;boundary=----ROPE----
     ----ROPE----
     Content-Type:image/jpeg
     Content-Range:bytes 0-100/2000
此处为0-100的数据
----ROPE----
Content-Type:image/jpeg
Content-Range:xxx-xxx/2000
xxx-xxx范围的数据.
----ROPE----

好吧,以上这些不是我们关心的重点.我们关心的是和缓存有关的情况,其实对于任何客户端(包括用户代理，以及各类缓存服务器)来说.如果它明确的知道自己想要某一部分范围的数据.就可以使用Range标头. 但事实上,比如对于浏览器来说,一般情况下,只有当服务器端的响应中包含Accept-Ranges:bytes标头时,才可能会在有断点续传需求的时候,自动使用Range头去请求实体.而代只有在响应中，明确出现Accept-Ranges:none时.才会完全避免客户端(包括缓存代理服务器),使用Range标头去获取部分数据.这是要区别看待的.

PS:Range头,还可以在GET方式下与If-Unmodified-Since标头配合,进行条件请求.其行为类似于If-Range头中使用日期格式做新鲜度校验.

.If-Range : 实体的Etag值 | date日期值.

配合Range使用的条件请求标头,该标头的值可以是被请求实体的Etag值，又或者是其Last-Modified的日期.客户端所缓存的部分数据,是新鲜的,服务器端才会,以206方式返回这部分数据.否则,以200方式返回全部数据.

响应标头:

.Accept-Ranges : bytes | none

用于说明,服务器是否支持范围请求.一般，我们常常为图片等资源设置Accept-Ranges:bytes标头.以便使客户端,可以使用断点续传功能.当然,这一切的前提是,客户端之前有缓存部分数据.或者换个角度说,如果服务器端明确声明,不允许缓存某个实体.那么断点续传也就无从说起了. 所以正确的服务器端配置.是一切的基础.

.Content-Range : bytes 0-xxxx/xxxx

标明当前服务器端返回数据的范围. /xxxx部分是总长度.

HTTP响应类别:
     .信息类：1xx(信息类响应头,是在1.1中才被真正具体定义.我们暂时不关注它.)
     .成功类：2xx
     .重定向类：3xx （我们目前只关注304,是的,304是属于重定向类的,我们姑且理解为,重定向到客户端缓存副本上去.）
     .客户机错误类：4xx
     .服务器错误类：5xx

关于客户端缓存，我们应该关注哪些概念

1. 寿命:

即响应的寿命,指从原始服务器发出实体后所经历的时间,或者是重新验证,证明某缓存仍处于最新状态（可信赖）之后,所经历的时间. 参考响应头中的 Age,其单位是秒.

2. 过期时间:

对于一个缓存实体来说，其过期时间,是由原始服务器设定的.(参考响应头中的Expires,Cache-Control:max-age…等)一但发现过期,则缓存,必须重新验证实体，才能决定是否使用缓存中对应的实体副本,作为响应.如果原始服务器,未设定过期时间,则缓存可以自己做主,设置一个它认为合适的过期时间(就浏览器来说,IE浏览器再这里实现的与众不同,非IE的主流浏览器,不会自作主张的设置一个自认为合适的过期时间,或者说他们总是认为这样的实体.不应该被缓存下来.而IE，则会有一个会话级的缓存.实际上也不是真正有一个过期时间了.所谓会话级缓存,即浏览器不关闭的情况下,始终去读取浏览器本地的缓存.而不会去试图做任何验证的工作.)

3. 新鲜期和陈旧性:（此概念为服务器端概念）

一个HTTP响应是在服务器端某个特定时刻生成的.原始服务器决定这个响应在多长时间内,是确定新鲜的.在这个新鲜期内,相同实体的请求.可以使用原来生成的那个内容作为响应.即服务器端缓存.一但原始服务器端确认某相同实体的响应,已过了新鲜期.即处于陈旧状态.则原始服务器,需要进一步处理这个响应,比如重新生成响应，或者验证是否可以继续使用该响应.并重新设置其新鲜期.

4. 有效性:

缓存,可以与服务器联系,来验证某个缓存副本,是否是可信赖的最新状态.这种检查，被称为有效性重验证.重验证也可以针对代理服务器进行,而不一定总要和原始服务器进行验证.

5. 可缓存性(缓存能力):

缓存者, 必须决定是否存对一个响应,进行缓存.这取决于很多因素,比如原始服务器是否允许响应被缓存,是否设置了缓存过期时间.而有时候即缓存者缓存了一个响应.它仍然需要对该响应，进行验证,以确保该缓存是新鲜的.缓存能力和响应验证，是紧密相关的.

那么协议就是全部么？用户代理就那听话么？我们理所当然的写一些东西的时候就可靠了么？

下面这段是我的evernote中翻找出来的一段和缓存有关的坑爹的例子.也算给我们自己提个醒. 用户代理可能应为某些原因,给我们造成一些困扰. 所以切记想当然. 一切应以实测为准. 同样.代理服务器也完全可以违背http协议相关的缓存策略.所以理论上很多东西，都是不可信的：

demo:

document.onclick = function () {
            var img = new Image;
            document.body.appendChild(img);
            img.src=https://passport.baidu.com/?verifypic";
            alert(img.complete)
            //CollectGarbage();
}

IE7+,opera 如果src是一个静态不变的地址.则不会再发起请求(无视http缓存相关头域).而直去取缓存文件。而且是完全不走network 模块的那种. 所以甚至httpWatch也不会抓到 cache 的项.
因为该img 会被保存在内存中. 即使没有 img句柄,而直接是一个 new Image().src=xxx 也是如此. 并且无论图片资源是否强制缓存.http头指定该资源不缓存,亦如此. 这也是为什么IE6有另外某个必须保持new Image句柄的原因.因为IE6 和 IE7+对new Image的策略完全不同， IE6是不会在内存中保持new Image对象的(这也是为什么ie6会有后面提到的那个问题的本质原因.).而 IE7+会在内存中缓存该对象. 并以url作为索引.opera12-也是如此.

所以,如果是借助new Image 上报，即使image资源的http 相关缓存头,配置正确(no-cache,no-store,expires过期).在IE7+和Opera12-中，也应该使用随机数.来绕过浏览器内存缓存new Image的坑. 但是不能因此而放弃配置正确的http缓存策略先关头. 因为这才是正道. 符合语义的做法. 随机数是为了修正用户代理的错误. 不能混淆或相互代替. 另外随机数，也可能是为了解决另外一个问题, 仍然和IE系列有关，比如未指定相关缓存头域情况下,IE系默认对资源有会话级缓存的bug.

而ie6 , 一个简单的 new Image().src=xxx 的上报. 会可能在GC(浏览器主动触发,如因页面渲染触发的GC,而不是主动调用CollectGarbage方法)时abort 掉这个请求.(此问题其他浏览器，IE7+都不存在.)

即使是
var img = new Image();
img.src= xxx 也如此

解决办法:
var log = function(){
var list = [];
return function(src){
    var index = list.push(new Image) -1;
list[index].onload = function(){
  list[index] = list[index].onload = null;
}
list[index ].src = src;
     }
}();
但是要注意的问题是: 0 content length or not image mimeTypes . 不会触发onload. 也就是说，上面的代码.有可能不会及时回收资源.这取决于上报的服务器的配置了. 也许可以借助onerror来综合解决。但我个人认为.这里不会造成内存泄露. 就算你一个页面有100次上报,也无所谓. 而且对于ie7 - ie10 pp2(更高版本还不好说)来说 .总是在内存中自动缓存每个new Image对象,那么是否我们主动使其持有句柄,其实意义也都不大了.

本文链接

html5 performance 的应用尝试.

2011-11-21T08:30:00Z

一切都在注释里了. 有兴趣可以看看.

要补充的是，这段代码的测试环境: Chrome11+,Firefox7+,IE9+, 别的浏览器就没办法了. 另外，代码适当使用了ES5的api . 如果不是为了这一点,那么其实这套api应该设计成另外的样子. 而不是属性器. 因为我终于是被IE9的兼容模式,给搅和了. 为了兼容.不得不设计出update 接口出来...

本文链接

HTML5 performance API 草案.

2011-11-07T02:50:00Z

支持浏览器: IE9+,Chrome11+,Firefox7+.

宿主对象window.performance.

参考资料:http://msdn.microsoft.com/zh-cn/office/ff975118

参考w3c的标准草案:http://w3c-test.org/webperf/specs/NavigationTiming/

目前,IE9+和 chrome11+,Firefox7+已经实现了该草案定义的接口.

成员:

.navigation (一个叫做performanceNavigation的对象.)

.timing (这玩意是一个被称作performanceTiming的包含了很多成员的对象)

方法:

.toJSON

返回一个对象，并抄写performance的可枚举成员到其中. 是的,timing,navigation都在上面.

JSON.stringify(performance.toJSON()) == JSON.stringify(performance)//true. 悲剧啊.明明是继承来的，msdn非要特殊标一下..

PS:

1. performance,仅能对当前的html文档做检测，所有的对象都和当前文档有关. 如果我们想检测某个图片资源的网络状况,则不行. 比如我们想监控，用户访问我们服务的状况，就只能创建一个iframe, url为我们服务某个地址(除非用户访问的当前页，就是我们要监控的对象.). 然后才可以监控这次一次请求的网络状态等等. 所以建议如果可以考虑使用performance,做监控，则需要有抽样、时间点等监控机制. 否则给服务器带来额外压力，得不偿失. 如果要监控其他资源，需要使用 ResourceTiming. 这套api. 这个会在其他帖子里单独说一说.

performanceNavigation(performance.navigation)对象的成员

performanceNavigation.type

返回值应该是0,1,2 中的一个.分别对应三个枚举值:

0 : TYPE_NAVIGATE (用户通过常规导航方式访问页面,比如点一个链接，或者一般的get方式.)

1 : TYPE_RELOAD (用户通过刷新,包括JS调用刷新接口等方式访问页面)

2 : TYPE_BACK_FORWARD (用户通过后退按钮访问本页面)

ps:草案中其实还有 3 : TYPE_RESERVED (保留,其他非前三种方式访问.)

performanceNavigation.redirectCount

一个只读属性,返回当前页面是几次重定向才过来的.但是这个接口有同源策略限制,即仅能检测同源的重定向.

bugs:

1. IE9,当一个同源的页面a连接到地址b(是否于a,c同源都如此),后被重定向到同源页面c时.navigation.redirectCount居然会是1.而不是0,此bug已被IE10 PP2修复.

performanceTiming(performance.timing)对象的成员:

.navigationStart

浏览器完成卸载前一个文档的时间(也就是准备加载新页面的那个起始时间).如果没有前一个文档，那么就返回 timing.fetchStart的值.

似乎只有Chrome 非常严格遵守了此草案. 即不把刷新页面，以及一个标签页输入地址到指定页面，视为发生文档的卸载

bugs:

1. IE9,当发生重定向时,.navigationStart 会是0. IE10 PP2 已修复此问题.

2. IE9-IE10 PP2,的一个问题是刷新当前页面,或在某个标签页输入地址为非相同页面时, 会被视为存在前一个文档，也就是说,其navigationStart会早于fetchStart.(除非在当前页再次输入地址按回车.再次进入该页面，则被视为无前一个文档被卸载.).而实际上这时候navigationStart,是unloadEventEnd的时间.

3. Firefox7-Firefox10,一个新标签页也会被视为一个有效的文档. 所以这时候,会有值，且不是fetchStart的值.

.unloadEventStart

如果前一个文档，和当前文档同源,返回前一个文档发生unload事件前的时间.如果没有前一个文档，或不同源,则返回0.

bugs:

1. IE9-IE10 pp2,Chrome17-,在前一个文档与当前文档中间发生重定向时, 且前后两个文档同源时, unloadEventStart,也会返回0

.unloadEventEnd

如果前一个文档和当前文档同源.返回前一个文档发生unload事件的时间. 如果没有前一个文档，或不同源,则返回0.

如果,发生了HTTP重定向,或者类似的事情.并且,从导航开始中间的每次重定向，并不都和当前文档同域的话,.则返回0

bugs:

1. IE9-IE10 pp2,Chrome17-,在前一个文档与当前文档中间发生重定向时, 且前后两个文档同源时, unloadEventEnd,也会返回0

.redirectStart

如果,发生了HTTP重定向,或者类似的事情.并且,从导航开始,中间的每次重定向，都和当前文档同域的话,就返回开始重定向的,timing.fetchStart的值.其他情况，则返回0.

bugs:

1. IE9-IE10 pp2,在页面a,链接到地址b,并重定向到与b同源的页面c时. redirectStart,将为0.即同源策略，居然会考虑导航页.

.redirectEnd

如果,发生了HTTP重定向,或者类似的事情.并且,从导航开始,中间的每次重定向，都和当前文档同域的话,就返回最后一次重定向，接收到最后一个字节数据后的那个时间.其他情况则返回0.

bugs:

1. IE9-IE10 pp2,在页面a,链接到地址b,并重定向到与b同源的页面c时. redirectSEnd,将为0.即同源策略，居然会考虑导航页.

.fetchStart

如果一个新的资源(这里是指当前文档)获取被发起,或类似的事情发生,则 fetchStart必须返回用户代理开始检查其相关缓存的那个时间,其他情况则返回开始获取该资源的时间.

.domainLookupStart

返回用户代理对当前文档所属域进行DNS查询开始的时间. 如果此请求没有DNS查询过程,如长连接，资源cache,甚至是本地资源等. 那么就返回 fetchStart的值.

bugs:

1. Firefox7-Firefox10,的实现有错误. 因为其值,并没有遵守标准所描述的对应时间节点.而是默认以navigationStart作为时间起点,并以中间的重定向时间做累加.而得到domainLookupStart的时间.即使这个重定向是非同源的重定向.所消耗的时间都会被计算进去. 那么，这也就解释了，为什么当没有重定向发生时, domainLookupStart - fetchStart, 我们往往会得到一个负值的原因,因为navigationStart,是要早于 fetchStart的.

.domainLookupEnd

返回用户代理对结束对当前文档所属域进行DNS查询的时间.如果此请求没有DNS查询过程,如长连接，资源cache,甚至是本地资源等. 那么就返回 fetchStart的值.

bugs:

1.参考domainLookupStart的bug. End具备相同的问题.

.connectStart

返回用户代理向服务器服务器请求文档，开始建立连接的那个时间,如果此连接是一个长连接,又或者直接从缓存中获取资源（即没有与服务器建立连接）.则返回domainLookupEnd的值.

bugs:

1. Firefox7 当资源走cache,即并未创建连接时. connentStart 的值为0.

2. Firefox8-Firefox10,当并未创建连接时,connetStart的值是fetchStart的值，而不是domainLookEnd的值. 但这里涉及到一个惯性问题，因为domainLookupEnd的累积时间就已经背离了标准了，所以即使connectStart遵守标准.也是一个有问题的值.

.connectEnd

返回用户代理向服务器服务器请求文档，建立连接成功后(注意，不是断开连接的时间.)的那个时间.如果此连接是一个长连接，又或直接从缓存中获取资源（即没有与服务器建立连接）,则返回domainLookupEnd的值.

bugs:

参考connectStart的问题.connectEnd具备同样的问题.

如果连接建立失败,而用户代理进行重连,则connectStart和connectEnd则应该是这次重连的相关的值.其中connectEnd必须包括建立连接的时间以及,SSH握手协议和SOCKS认证等时间.

.secureConnectionStart

可选特性.用户代理如果没有对应的东东,就要把这个设置为undefined.如果有这个东东,并且是HTTPS协议,那么就要返回开始SSL握手的那个时间. 如果不是HTTPS, 那么就返回0.

补充:Firefox7-10,IE9-IE10 PP2,都木有实现这个api.所以始终是undefined.

.requestStart

返回从服务器、缓存、本地资源等,开始请求文档的时间.

如果请求中途,连接断开了,并且用户代理进行了重连，并重新请求了资源,那么requestStart就必须为这个新请求所对应的时间.

performance.timing 并不包含一个单表请求结束的"requestEnd"接口. 原因有两点:

1. 用户代理所能确定的请求的结束,并不能代表正确的网络栓书中的结束时间. 所以设计这个属性并没什么用处.

2. 一些用户代理，如果要封装一个代表HTTP层面的，请求结束时间的接口,成本会非常高昂.

bugs:

1. Firefox7,直接走本地缓存时,.requestStart的值将为0. (Firefox8已修复此问题)

.responseStart

返回用户代理从服务器、缓存、本地资源中，接收到第一个字节数据的时间.

.responseEnd

返回用户代理接收到最后一个字符的时间，和当前连接被关闭的时间中，更早的那个. 同样,文档可能来自服务器、缓存、或本地资源.

补充: 此值的读取应该是在我们可以确保真的是Response结束以后. 比如window.onload. 因为考虑到chunked输出的情况. 那么我们脚本执行，并获取该值时，响应还没有结束. 这就会导致获取时间不准确.

bugs :

1. IE10 PP2, 以及Chrome17- ，走本地缓存时.在文档中间的脚本执行时去读取此值, 将为0. IE9本来没有问题,结果IE10 PP2,反倒有了问题.

2. Chrome16-,(Chrome17,已修复此问题.)在地址栏输入相同地址,走本地缓存时. responseEnd的时间，居然早于responseStart的时间. （不得不承认，这简直就是奇葩啊!）

3. Chrome17-,从页面a,到地址b,再重定向到地址c, 此时如果地址c是走缓存.则. ResponseEnd的时间，会遭遇ResponseStart的时间.(好吧,我们把希望寄予Chrome18好了.)

实现差异:(由于草案中，并未提及,当文档被分段输出后.在中间文档数据，接受过程中,responseEnd应如何处理,导致浏览器实现存在差异.)

IE9 - IE10 PP2 , Firefox8-Firefox10,在不走存在Response阶段（非走cache的情况下.）.以接收第一个chunked包结束的时间作为.responseEnd的时间.(这将导致后续的一系列问题.)

Chrome17-,Firefox7,则在分段数据的接受过程中，不会更新.responseEnd的时间,其值,始终为0.

.domLoading

返回用户代理把其文档的 "current document readiness" 设置为 "loading"的时候.

(current document readiness 其实就是document.readyState API对应的状态.)

参考:http://dev.w3.org/html5/spec/dom.html#current-document-readiness

bugs :

1. IE9. 在分段输出文档的情况下，该值总是要晚于最终responseEnd的值. 基于responseEnd的IE实现的bug.这也合情合理.

实现差异:

iE9 - IE10 PP2 , 当文档是chunked方式输出的时候.总是要等最后一个chunked被浏览器接收后,domLoading才会有有效值. 也就是说,IE中目前的状况是.domLoading.无论如何，都要晚于responseEnd.其他浏览器则无此问题. 但是这个问题导致我们计算IE下DOM Parse不准确. 即 domInteractive - domLoading 甚至会经常得到0.

.domInteractive

返回用户代理把其文档的 "current document readiness" 设置为 "interactive"的时候.

从标准来说,domReady的状态为"interactive"时,意味着,文档解析结束了. 因为标准中描述, DOM树创建结束后第一件事，就是把 "current document readiness" 设置为"interactive"

参考:http://dev.w3.org/html5/spec/the-end.html#the-end 中第一步.

bugs :

1. IE9,IE10 PP2 . 在分段输出文档的情况下，该值并不是全部文档解析完成后的时间,而是第一个数据块被解析完成的时间,基于responseEnd的IE实现的bug.经过向后推定这也合情合理.

实现差异:(由于草案中，并未提及,文档解析并未结束时,其默认值的应该是多少.导致浏览器实现有差异.)

按我个人理解，并未解析结束，应该为0. 但是IE似乎对这个东西理解不太一样. 其他浏览器会是0. 但是. IE9-IE10 PP2,则会比较有趣.即使是分段输出,我取到的值.也和onload以后去到的,domInteractive的值是一致的. 导致这一神奇现象的原因是,正式IE系的bug所导. 该时间是错误的引用了,DOM解析完成第一个数据块的时间.而不是整个文档的. 但是纠结起来就要挖掘更深层次的原因了. 因为草案只说该值体现的是,用户代理把"current document readiness" 设置为 "interactive"的时间.如果IE系处理分段输出的html文档，向来都是这样做的。那么该值与其他浏览器的差异。也是可以理解的.

.domContentLoadedEventStart

返回文档发生 DOMContentLoaded事件的时间.

参考:http://dev.w3.org/html5/spec/the-end.html#the-end 中第4步.

DOMContentLoad和 DOMInteractive 之间差了两个步骤. 其中之一是, 所有open elements出栈，然后去看看待运行的script list中是否有需要运行的脚本,如果有则执行，一直到这个列表为空了.再触发DOMContentLoad. 需要主的是这个待运行脚本列表.有些可能在不同浏览器中，被加入进去的行为可能不同. 比如 document.write写入文档流的脚本，以及script deferr 的脚本.. 所以我们应该知道deferr的脚本也是要他推迟domContentLoaded的，也就是我们最常用的所谓domReady.(至少html5的规范是如此.)

.domContentLoadedEventEnd

文档的DOMContentLoaded 事件的结束时间.

补充:所谓事件结束的时间，是指，如果DOMContentLoaded事件被开发者注册了回调事件.那么这个时间的End时间减去Start的时间.就会是这个回调执行的大概事件. 当然居于部分浏览器实现可能会有2-3ms的误差. 但是这个时间，基本可以忽略不计. 类似的情况还有后面的.loadEventStart,End. 即 window.onload 所有回调所消耗的时间.

.domComplete

返回用户代理把其文档的 "current document readiness" 设置为 "complete"的时候.

PS:如果 current document readiness 的某个状态被多次触发，那么对应的 domLoading, domInteractive, domContentLoadedEventStart, domContentLoadedEventEnd and domComplete这些对应的API返回的时间,就应该是这个状态第一次触发的时间.

.loadEventStart

文档触发load事件的时间. 如果load事件没有触发,那么该接口就返回0.

.loadEventEnd

文档触发load事件结束后的时间. 如果load事件没有触发,那么该接口就返回0.

external : 另外,我很期待微软的私有实现,msFirstPaint 的属性。能够得到标准的采纳...这样对于监控浏览器首次渲染花费的时间.有太重大的意义了。

有了这些东西，我们大概能做什么呢，大家自由发挥想象吧... 一个有趣的事情是，有时候bug,未必是坏事。我们可以利用bug.可以统计到一些额外的信息.比如:

IE,Chrome,利用 unloadEventStart,End, 以及 document.referrer .与当前文档同源的前提下，值为0来断定该两款浏览器,发生了跨域的重定向.而Firefox则可以考虑用domainLookupStart 是否大于navigationStart .以及redirectCount是否为0.来达到相同的检测目的..

最后附上timing相关的图,可以帮助你理解这玩意的意义:

本文链接

Object.defineProperty 接口浏览器实现的bug.和疑惑

2011-04-27T08:38:00Z

先看看 MSDN上的描述.

Adds a property to an object, or modifies attributes of an existing property.

Object.defineProperty(object, propertyname, descriptor)

Arguments

object

Required. The object on which to add or modify the property. This can be a native JavaScript object or a DOM object.

(can be 不等于 must be啊. IE8到底搞什么？另外Safari并不允许DOM object.)

propertyname

Required. A string that contains the property name.

descriptor

Required. A JavaScript object that is a descriptor that describes the property. The definition can be for a data property or an accessor property.

Return Value

The object that was passed to the function.

Remarks

You can use the

Object.defineProperty function to do the following:

Add a new property to an object. This occurs when the object does not have the specified property name.
Modify attributes of an existing property. This occurs when the object already has the specified property name.(参考后面的注释1)

The property definition is provided in a descriptor object, which describes the attributes of a data property or an accessor property. The descriptor object is a parameter of theObject.defineProperty function.

descriptor 参数: (参考 ECMA262 Edition5 8.12.9章节)

Data descriptor attribute	Description	Default if not specified when you add a property
value	The current value of the property.	undefined
writable	true or false. If writable is set to true, the property value can be changed.	false
enumerable	true or false. If enumerable is set to true, the property can be enumerated by a for…in statement.	false
configurable	true or false. If configurable is set to true, property attributes can be changed, and the property can be deleted.	false

BUG:

1. IE8,普通的 new Object 无法使用此接口.

var o = {};
Object.defineProperty(o,'abc',{value:123}); //抛出异常,不是因为别的.仅仅因为 o是一个普通的js object.
o.abc = 300
alert(o.abc);

而如果 o = window 或一些 DOM Element 等宿主对象就可以使用此接口.但并不是所有宿主对象都可以. 另一个重要的问题是. 对于Attributes参数缺省情况下,IE8也没有实现 o的abc属性的默认只读.即使,显式加上 writable:false.也如此.不知道这个接口被IE8实现成这个鸟样子,到底还有什么用.

2.IE8 Configurable:false

var o =window;
Object.defineProperty(o,'abc',{value:123,configurable:false});
delete o.a //IE8此处抛出异常.
alert(o.abc);

也就是说.configurable 完全没有意义. 其现象就就如同一个固有的bug那样.参考代码:

window.o = 123;

delete window.o; // IE8 抛出异常. 同样是对象不支持此操作.

3. obj 为window宿主对象模拟 Const.

Object.defineProperty(window,'abc',{value:123,writable:false});
abc = 200;
window.abc = 300;
alert([abc,window.abc]) // ie8,Safari5 300,300 | Chrome,Ie9 123,123

这里就涉及一个很郁闷的问题.IE8 SUCKS,我可以理解但是Safari跟着凑什么热闹呢？好在, 如果我想要的是模拟 Const 的话 Safari4 早就支持了. 所以我们可以假设IE9+ 可以用这个来模拟 Const 哦.

当然,如果window 换成一个普通的 object, Safari则无此问题.所以这应该是Safari 对宿主对象实现此接口的一个bug.

注1 : 此问题我仍然有点迷惑.至少从ECMA62 Edition5中的相关定义.感觉所有浏览器的实现都没符合标准.或者是我对标准的理解有误.

参考代码 :

var o = {abc:123};
Object.defineProperty(o,'abc',{value:200,Writable:false}); // writable 而不是 Writable. 写成大写.就被认为特性是缺省的。然后 IsDataDescriptor 就会false.
o.abc = 300;
alert(o.abc)//支持defineProperty的浏览器都打印300. 即writable:false,失效了

对于对象o,已经通过[[Put]]内部方法设置的属性来说(o.abc =123或例子中json方式),这个属性就是一个 data property .（区别于accessor property,setter getter属性.）其特性集（Writable,Configurable,Enumerable）都会被设为true. 而 {value:200,Writable:false} 这个descriptor object,因为具备value特性. 结果就是对他们俩进行 IsDataDescriptor内部运算的结果就将是, 两个就都是true. 而最终进入步骤 10.b(else, the [[Configurable]] field of current is true, so any change is acceptable. 参考8.12.9章节).也就是新的特性应该被应用上去.那么测试代码的结果就让我感到迷惑了.

而观察DefineOwnProperty的步骤.发现大概只有在进入步骤 9.b.i 即. 即把abc这个data property 转换为了一个 accessor property.而特性操作就被无视了. 但是进入步骤9的条件是. abc属性的descriptor 和 {value:200,Writable:false} 至少有一个在做 IsDataDescriptor运算时返回false. 但是这一点,在测试代码中明显不可能. 所以我困惑无比.

我更希望是我对标准的理解有错误.而不是浏览器的实现都有问题.期望我能更早的找到这个问题的答案.

对于这个疑惑终于有了答案. hax,指出了我的悲剧. 我的 descriptor 的特性名,首字母写成了大写.所以默认为忽略了. 所以实际上就是进入了 9.b.i 了. 之前特性名都写成大写。之所以感觉上是生效的，是因为默认的都是false. 悲剧的人生啊... 留此贴纪念一下我的悲剧.

本文链接

window.open 浏览器差异.

2011-04-06T07:28:00Z

首先引入 w3help的,莫的测试: 原帖地址:http://www.w3help.org/zh-cn/causes/BX1053

w3help的测试,和我的测试相互补充,应该比较完整了.悲剧的是我做完测试后,和莫提了一嘴,他告诉我w3help有啊. 我累个去.咋不早说.我可以省不少事呢.

建议先看看w3help的.内容比较详细.尤其是据说 window.open,这种宿主方法.居然,可能在将来被html5所统一.期待啊.

浏览器实现差异:

.一个open的窗口被拦截后, Opera11- ,Chrome11- 仍然会有窗口句柄. 而Safari是undefined ,IE 和 Firefox 则是 null. 而Opera,Chrome拦截掉窗口后.这个窗口的window.closed属性为false.

(所以在不考虑Opera和Chrome的情况下.可以用 !!win 来判断窗口是否被拦截. 而win.closed没有更大的意义)

.sougou高速浏览器2.1+ IE内核下,会无视该弹窗是否为响应用户鼠标操作的回调（a 和 input button 以及button等点击类交互标签是不被拦截的）.而一律强制拦截弹窗. 而且用a标签的click()也会被拦截.(好在,IE内核下,被拦截后,win 都是null.可以检测出来,用跳转代替,遗憾的是chromium内核下同chrome一样.被拦截时，无法检测.要检测chrome,opera的弹出,比较麻烦,弹一个about:blank,Opear检测documentElement是否存在,chrome则需要检测documentElement.clientWidth === 0)

.各个浏览器使用window.open,第三参数效果:(应注意,如果连续写多个参数,应以 ","号分隔.如果其中某个参数名有错误,则可能导致整个第三参数在,Chrome和IE浏览器中失效)

浏览器

无参数

width,height

left,top

toolbar

location

Directories

Status

Menubar

Scrollbar

Resizable

screenX,screenY

FullScreen

期待结果

有标签的标签
无标签的弹窗

尽量按指定
宽高弹窗

语义冲突的参数
相对parent页
left ,top位置

默认无工具栏
yes 有工具栏
no 无工具栏

默认有(r)
yes 有(w)
no 无
(r)只读,(w)可写

这玩意到底
是神马？
只有IE6支持
无期待结果

默认无
yes 有
no 无

垃圾参数
无视.
只对早期
ie有效

默认auto
yes auto
no 无

默认是
yes 是
no 否

真正语义上的参数
相对屏幕坐标

全屏显示

6 弹窗

7-8 弹窗

9 标签

全部 ok

(注1)

全部

默认无

yes 有
no 无

6
  默认无
  yes 有(w)
(toolbar也有了)
  no 无

7,8,9
  默认有(r)
  yes 有(w)
  no 有(r)

6
toolbar去掉
location部分

7,8,9不支持

6,7,8
无视参数
始终有

9
默认无
yes 有
no 无

全部
无视参数
始终无

全部
默认否
yes 是
no 否

不支持

全部
支持

Chrome

全部标签

全部 ok

全部相对

父页面

left,top

不支持此参数
弹窗木有工具栏

不支持此参数
始终有,且只读

不支持

无status bar

1
无视参数
始终无

2+
默认 auto
yes auto
no auto

不支持此
参数,一律
可缩放

完全 ok

不支持

FireFox

1, 1.5 弹窗

2.0+ 标签

全部 ok

全部
left 相对父页面left

top 相对屏幕

默认无

yes 有
no 无

1, 1.5, 2
默认无
yes 有(r)
no 无

3+
无视参数
始终有(r)

不支持

无视参数
始终有

无视参数

始终无

2-
默认否
yes 是
no 否

3+
不支持此
参数,一律
可缩放.

完全 ok

3.6-
不支持

4
支持

Safari

3+ 弹窗
(Safari5 偏好设置
,在标签中打开新
页面, 选项有-总是
,永不,自动.默认是
永不.导致此问题.)

3+ ok

全部
left 相对父页面

(但当父窗体left的

位置导致新窗体不

能全部显示时,则

新窗体left,相对屏

幕为0,与ie7有些

相似)

top 相对屏幕

默认无

yes 有
no 无

默认无
yes 有(w)(但
工具栏也有了)
no 无

不支持

默认无
yes 有
no 无

无视参数

始终无

不支持此
参数,一律
可缩放

完全 ok

不支持

Opera

9.2+ 弹窗

9.2 tab

9.6+

标签(有宽高,可拖

拽.但无法离开父

窗口)

9.6+

相对父页面

的left,top

9.2 标签

9.2 tab

9.6+ 因其本质
是tab所以无视
此参数.一律无
toolbar

9.2 tab

9.6+ 因其本质
是tab所以无视
此参数.共享

location

不支持

9.2 tab

9.6+ 因其本质
是tab所以无视
此参数.共享

statusbar

无视参数

始终无

不支持此
参数,一律
可缩放

不支持

360安全

3.3+ 标签

3.612 弹窗

3.612 弹窗(无视
宽高参数parent
页面多大新弹窗
就多大)

其他版本标签

3.612 left top
和parent页面
有关,但位置算
法很混乱.

其他版本标签

3.612 弹窗无视
一切参数.显示
一个完整窗口

其他版本标签

360高速

两种内核都标签

IE内核标签

chromium都 ok

chromium

同chrome

其他内核标签

搜狗高速

两种内核都标签

标签

QQ5

两种内核都标签

标签

Maxthon2.5

标签

Maxthon3

两种内核都标签

标签

世界之窗

标签

MyIe

标签

ps：表中测试,有冲突的一些项目就不记录详细数据了,地方有限.意义不大.比如 location = no , toolbar=yes 或反之. Safari下是只有有一个是yes就都会有. 而ie6则很有趣.会分的很细.

第二参数target(name)相关:

用途:

.参考 target =_self , _blank , _top , _parent , target ,还有传说中的_newtab ,神马的.据说可以让ie7+ 不弹窗而是打开新标签.但是我测试失败了.求高人指点.

.为窗口对象设置name属性-window.name.

.所以对于同一个浏览器来说,各个窗口的name是具备唯一性的.(opera9.6+ 开始有些特殊.)

.也就是说, 如果已经存在一个窗口对象的name为abc.则后面再次window.open(url,'acb')的话.那么只会操作这个窗体对象的url,导致跳转或reload(false).无论它是iframe还是一个被open的独立的窗体

差异:

.IE下target(name)的值不能包含如.、& 等特殊字符.否则会报参数错误.(解决办法.避免使用包含特殊字符的字符串,作为name的值)

.IE下name的值为null 或 undefined时,行为与其他浏览器有差异. 等价于 'null' 或 'undefined' .在期望打开多个窗口,又想设置其他窗口参数时,参数设置此2值.会被视为有效的name值. (解决办法,使用 '' 空字符,或'_blank'代替 null 或 undefined. 建议用优先考虑空字符,因为某些浏览器的早期版本不支持 _blank)

.一个已经open的窗口，再次使用相同name,进行window.open操作时,个别浏览器可能不会保证该窗体的可见性(在最上层显示).比如Firefox在最小化某窗口后.(解决办法:可以借助win.focus() 操作强制该窗口在最上层显示.)

.Opera,Chrome 下，如果一个iframe的id,与window.open的第二参数name同名.也具备同样效果. 其他浏览器则无此现象.

.Opera9.6+ ,如果在另一个iframe内调用其self.open的第二参数name与其他iframe的name或id同名,则仍然会重新打开一个窗口. 而不是去操作该iframe.其他浏览器则无此问题

注1

IE6. left 一个奇怪值,top 相对屏幕

IE7. left 相对的位置,总是相对非最大化时,父页的left+10px左右偏移.(就是非最大化时,显示在哪,最大化时,就显示在哪.但并不总是相对非最大化时的父窗口left,比如在父窗口left很靠右的情况下,则其会新窗口会变成相对屏幕来显示)

top 相对屏幕

IE8. left,top全部相对屏幕

IE9. left 同IE6类似top 相对屏幕总是0

本文链接

Chrome v8引擎对多行注释,做词法分析时的bug.

2011-03-20T09:51:00Z

此BUG,已修复了. 具体哪个版本修复的,我懒得去验证了，我手里的15,16已经是修复了...

先看一个注释的写法:

/* 个/ */

这个在chrome下会抛出异常.

Uncaught SyntaxError: Unexpected token *

原因是,汉字个的 Unicode 为 4e2a , 而chrome的程序员,为了加速词法分析,简单的使用了下面这种逻辑:

1,扫描到/* ,就快速向后搜索,一但遇到 code point为 2a+\u002f 的情况,他就简单认为这是 */ .所以认为注释结束了. 然后直接忽略掉注释部分，（即把他们从输入元素流中踢出去.注意我之所以提到直接忽略,是因为这里还隐含另外一个bug. 具体的后面解释）. 然后继续向后扫描,这时候它遇到了 * ,. 因为这玩意属于ECMAScript的标准的token之一.即属于标点符号中的一个.可能是一个乘法运算符. tokenizer把他作为一个token处理鸟. 那么语法分析时就会是个悲剧.

所以,比如什么伪/ 等code point是**2a的和/在一起出现在多行注释内. chrome就注定悲剧.但是异常信息会有可能不同, 这完全取决于, 伪/ 后面是什么. 比如后面还有 /,那么语法分析时,甚至会认为你这里存在一个错误的正则表达式直接量相关的异常.比如未闭合的,正则表达式文法的 goal symbol.

我觉得chrome的程序员大概是认为,注释都是ascii字符.因为ascii字符中只有*星号是符合**2a的字符. 如果这样的话,我们有理由举起个反对语言歧视的牌子.去喷google. 毕竟这么多国家,这么多语种的程序员.写注释都得写英文么？

再说说另外一个关于词法分析期,chrome 对多行注释扫描,偷懒的现象. 当然,这个问题,不仅仅是chrome有.还有一些其他浏览器.

参考下面的代码:

alert(function(){
return /*
*/ 1;
}()); // 打印1的,没有遵守标准.

ECMA262 Edition3,5.中对于多行注释中,存在行终结符的情况,都是一致的.要求这个多行注释,不是简单的被忽略,而是要被替换为一个行终结符插入到流中.而一旦return 和 1之间的多行注释被替换为一个行终结符,则ECMA262的自动插入分号机制,就要产生作用.自动在token 1前面加入分号.那么打印undefined.才是符合标准的做法.

对于这一点,浏览器的实现并不一致.

IE6-IE8, Firefox0.8-Firefox3.0, Safari5-, chrome11- 都打印1.即并没有遵守标准.

而 IE9 , Firefox3.5+ , Opera11-(测到9.2),则打印undefined,遵守了标准.

补充说明:xxx版本号-的形式 ,就是这个版本之前(包括这个版本)都如此.

本文链接

IE9的特性变化,(收集贴)

2011-03-16T06:16:00Z

ie9 仍然未改变的一些不好的部分:

.未配置 Expires max-age , no-cache ,no-stroe 时默认仍然有会话级的缓存.存在

.getElementsByName 仍然只对表单元素有效.

.仍然不支持 window.XPathEvaluator 方法.

.仍然不支持 XPathResult

.仍然不支持 window.open 方式的postMessage 通信.

.仍然不支持 onpageshow onpagehide

.同ie8类似. el.setAttribute('onclick',''); 只能工作在非怪异模式或兼容模式下.

.仍然不支持正则对象的exec简单调用方式. /./('123')

.仍然不支持 __proto__ 或 __defineGetter__ 等好用的非标准的东西.

.仍然存在 iframe缓存bug...

.对于动态添加的scriptElement,仍然无法保证执行时序.

.仍然不支持 rgba.

ie9 改变的一些商榷的部分:

. for in顺序与chrome opera一样使用了一种变态的ascii排序.

. 对于已存在的一个script节点,修改其src属性,后虽然仍然能发起一个http请求,但是新被请求的脚本却不会被执行.

. 不在支持document.createElement('<div id ="abc">123</div>');这种参数格式了.

.window.ScriptEngineMinorVersion();始终是0 . 引用莫的话: 返回值直接依赖于所使用的 Scripting 语言的动态链接库 (DLL) 中包含的版本信息

.不再支持IE系特有的可以访问调用者的arguments对象的接口,arguments.caller了.

.居然可以枚举arguments对象了.这真是一种历史的倒退啊.

ie9 改变的一些令人愉快的部分:

.支持 set get关键字鸟.(chrome1+ , safari3+ , firefox1.0+ , opera9.6+ 就都支持了.而IE9终于支持了.)

.开始支持ECMAScript262 Edition5 中的一些新方法了.如:

.Object.defineProperty (此接口只有chrome比较新的版本,ie8+,Firefox4+,Safair5 支持,Opera11仍然不支持..)

.Object.definePropertys ( 同defineProperty一样,这个IE9很光荣,先于Firefox4支持,且Opera11仍然不支持.)

.Function.prototype.bind

.Object.prototype.getPropertyOf

.终于支持'\v'垂直制表符了.

.终于[,].length ==2 鸟.

.终于支持 document.defaultView接口了

.也支持getComputedStyle接口了.

.支持getElementsByClassName了.

.frames === window 终于true了. 即 window.frames 终于不再是window的一个浅表copy了

.支持window.DOMParser XML转换对象了

.去掉了初次在global上查找window 宿主对象时的惰性绑定机制.

.修复for s in obj 时 obj为非静态问题.

.window.a =1; delete a; //true.

.eval 和(1,eval) 的区别终于在IE9被实现了.

.抛弃了对老的dhtml接口的支持. 如 element.setExpression 等相关老接口.

.终于支持script 的onload 和onerror鸟

. window.x = 1; delete window.x;//终于是true,且不抛异常了. delete 1;//终于是true,而不抛异常了. 不论对错.至少统一了浏览器的行为.

.终于Array.prototype.toString->Array.prototype.join方法中遇到元素为undefined的情况,不再会责任链查找到,Object.prototype[n]上面了.

.终于对new String()对象实现了索引器了.而不是像IE8那样,仅仅是string 直接量才能用索引器.

.new Image().complete 属性,终于如Safari,Chrome,Opera.那样仅仅在语义上表示图片是否被加载完成.而和是否被浏览器缓存无关了.但要注意此值受其模式影响,譬如怪异模式.则会变成老样子.

.终于支持 window.ondragenter dragover 鸟.(Opera11还不支持呢.)

.支持 addEventListener 等DOM2的API了. 但应该注意. addEventListener注册的事件侦听. 用fireEvent无法触发.必须使用对应的dispatchEvent.标准DOM API. 否则需要使用attachEvent去对应fireEventAPI.

本文链接

关于p3p 简洁策略,以及浏览器的支持情况.

2011-03-16T05:31:00Z

简述部分摘自某本关于P3P隐私策略的书籍.

而部分详细的表格来自w3.org.

而相关测试数据出自本人测试.如有遗漏或错误,欢迎指正.

浏览器	默认允许第三方Cookie	是否支持P3P	禁止第三方Cookie后,配置P3P简明策略头的效果	补充
IE6	否	是	HTTP可读写Cookie JS可读Cookie 首次读到P3P头,JS无写Cookie权限.第二次才OK (第二次.直接Cache.也不行.除非第一次非Cache并读到p3p头.后面我会提到解决方案.)	避免JS的写操作
IE7-IE9	否	是	HTTP、JS,可随意读写.	-
FireFox	是	否	HTTP、JS都不可读写	-
Chrome	是	部分支持,趋势-否	趋势为HTTP、JS可读不可写.	-
Safari	否	否	HTTP、JS可读不可写	借助Post提交表单,实现写操作.
Opera	是	否	JS可读写 HTTP可读不可写.	-

博客园_Franky

IE6 与 GZIP, BUG汇总

ES3和ES5中函数调用(function call) 的浏览器实现差异.

你应该了解的 一些web缓存相关的概念.

html5 performance 的应用尝试.

HTML5 performance API 草案.

Object.defineProperty 接口浏览器实现的bug.和疑惑

window.open 浏览器差异.

Chrome v8引擎 对多行注释,做词法分析时的bug.

IE9的特性变化,(收集贴)

关于p3p 简洁策略,以及浏览器的支持情况.

你应该了解的一些web缓存相关的概念.

Chrome v8引擎对多行注释,做词法分析时的bug.