假期长的一个好处就是,说不定很快就会闲的略感无趣想找些事情来做.
即使之前可能还想着终于可以休息了.
在家今天,心血来潮就想着写个chrome的代理扩展.
之前一直在用Proxy SwitchySharp.
想重新造轮子的原因也并不是不好用.
只是实在找不到什么事做.
另外一个原因是每次换个设备就要重新添加代理规则.
虽然也有现场的GFW list,但到底有多数其实是不用的.
于是,基于这个动机,开始便打算改改switchysharp,加个同步功能好了.
但是在看了相应代码之后,考虑到license是太喜欢GPL,于是只好放弃.
向上游的switchy plus看也是一样,GPL license.
只有原始的switchy是除GPL和MIT dual license的.
只是不知道具体什么情况是GPL,什么情况是MIT而已.
发邮件问作者,也没回复.
看来英文表达实在是太不堪入目了吧.
所以,只能重新开始.
不过要真是从switchy开始的话,改动还是挺大的.
毕竟历史原因,switchy时代chrome还没有原生的proxy只是,所以只能生成pac script然后通过对于OS的native 调用去修改系统代理设置.
看了下chrome的proxy api,其实也就三两行而已.
原则上来说,这几行就足够了.
手写一些pac然后save的local和storage里的话,就行了.
但浏览API的时候发觉似乎能够拦截浏览器请求,于是想,检测下RESET之类的,自动添加生成也省一些功夫.
于是,拦截了一些比较大几率是GFWed的失败请求,然后生成pac自动apply了.
到这里,本来也没什么事了.
但是忍不住想把能合并的规则,比如a.wordpress.com,b.wordpress.com之类的合并为*.wordpress.com.
于是这几天的事情就是调试这个.
结合自己几天的使用下来遇到的一些edge case,只尝试合并了二级域名以上的.
不然,像a.org,b.org之类的很容易合并为*.org,最后就变*了.
另外一点就是最初其实考虑到storage的大小限制,所以在记录失败网站的时候加入了计数器.
原始思路是想如果超出storage限制的话,自动抛弃计数小的.
毕竟,数值小代表访问频率低.
但最后还是没把这个限制检测加进去.
因为实际看了下自己的使用情况,实际条数也不多.
而且真到有必要的时候,大概也比较容易吧.
遇到的一些问题,比如偶尔浏览器会卡住一段时间的现象.
如果不是最近chrome版本自身问题的话,那就应该是并发访问一些数据结构造成的race问题吧.
也懒得去验证了.
简单地用alarms做延时修改和合并.
因为文档上指alarms的触发时间只是大约的限制,并不严格.
而且开发时候也没遇到特别严重的延时,大致能接受.
但是放到chrome store上之后,似乎就延时比较严重了.
推测是开发时候的调度优先级高一些吧.
于是只好最终去掉.
反正调度有延时,那竞争情况也顺应地会少些吧.
于是最终产品就是类似这样的.
http://goo.gl/HMZ5H
然后简单地写了个配置页面方便添加代理服务器.
至于实际使用起来,还是有些不太友好的地方.
如果网页是被RESET,那自然很好,刷新一下就可以了.
但是如果是一些干扰性的,比如DNS污染或者干脆连接干扰,造成页面长时间加载不出来的话,只能等最终timeout再刷新了.
有想过想switchy系一样支持手工加入规则.
后来想想还是算了.
毕竟涉及用户交互,要容错的地方比较多.
行数应该少不了.
另外一点就是,看API的时候看到似乎能够直接修改请求结果.
这样的话,理论上,加个background page,然后把goagent之类的用javascript实现一遍也是可以的.
或者直接透明修改请求应该也可.
最后一点是关于这个窥探请求带来的一些风险问题.
毕竟所有请求内容都是可见的.
如果用来做些其他什么事情,加上用户可能不太关注的话,很容易出问题.
所谓技术的中立性嘛,协议或者API什么的本身并没有好坏之分.
关键在于用的人.
尽管,设计的开始就应该考虑到这类API可能被滥用带来的问题.
但是,凡是考虑也都会有疏忽的地方,免不了一些看似常规的手段滥用.
就像TCP至于GFW.
技术角度看,完全是合理而且优雅的.
Don`t be evil.
没有评论:
发表评论