|
15楼#
发布于：2014-10-17 20:17
期望OpenH264 编码器早日能用来编解码 H.264 格式音频和视频。
|
|
|
16楼#
发布于：2014-10-17 21:14
Display which elements have listeners attached
https://developer.mozilla.org/en-US/docs/Tools/Page_Inspector#Examining_event_listeners From Firefox 33 you'll see a "ev" icon next to elements that have event listeners bound to them 另外这个也很重要 要说两次 https://developer.mozilla.org/en-US/docs/Components.utils.exportFunction Components.utils.exportFunction(func, targetScope[, options]);options : object |
|
|
|
17楼#
发布于：2014-10-17 21:32
大道有狐：今天好象已经撞上了OMTC的bug：A标签页切换到B标签页时，出现了一个混合了A-B标签页内容的画面。正在试图找出重现问题的方法，找到了就去报bug。。。使用通过 HTTPS 方式来连接到 HTTP 的代理服务器。 原文为“Support for connecting to HTTP proxy over HTTPS” 指的是通过https连接到代理（http、spdy、websocket） 目前没有gui设置入口 只能通过pac设置 具体到你这个情况 也就是如果goagent本地监听端口支持https firefox就可以通过https连接到goagent本地端口 至于goagent和远程gae的连接方式（goagent的http、https模式）完全和firefox无关 |
|
|
|
18楼#
发布于：2014-10-17 22:07
|
|
|
|
19楼#
发布于：2014-10-17 22:48
OMTC功能在我这里感觉不明显。
我对FF不最不满意的地方就是有时候响应很慢，特别是鼠标手势。以前不是特别清楚，但最近慢慢摸到门路了，如果一个网页载入的很慢，在载入没有完成的时候鼠标手势有时候就会失效，在很少的情况下甚至FF自己的反应也会变慢。 33版本这个问题还是没解决，公司的网络环境比较糟糕，总有人在内网下载什么的，有时候打开网页就特别慢，这种情况下我的FF不管是以前还是现在的33版本起码鼠标手势什么的响应速度一直没改善。 |
|
|
20楼#
发布于：2014-10-17 22:53
pcxfirefox：使用janus也会用到这个特性 只是在33上有速度缓慢异常的bug 官方在34上修复了回到原帖janus本质上就是个spdy代理嘛 function startProxy() {
var proxy = new SpdyProxy(CONFIG);
proxy.listen(CONFIG.proxy.port);
}bug 1079484？ 那也不影响connecting to HTTP proxy over HTTP啊 比如我的本地privoxy代理 目前设置通过https连接http代理的唯一方法是在pac中指定https 本论坛能有多少人会用到这个新特性…… |
|
|
|
21楼#
发布于：2014-10-17 23:39
aaaa007cn：使用通过 HTTPS 方式来连接到 HTTP 的代理服务器。先感谢你解释了”Support for connecting to HTTP proxy over HTTPS“这句话的含义。我明白你的意思了。 但我仍旧有疑问的是：在安装了autoproxy的我的firefox上，autoproxy已经接管了firefox本身的代理设定，因为在”选项-->高级-->网络-->设置“里已经是autoproxy的设置画面了。具体到一条代理规则，例如我用来测试的"||bbc.com"这条规则下，当在地址栏输入并转到http://www.bbc.com/时，autoproxy会根据前面定义的代理规则将数据包通过http协议发送到本地代理端口127.0.0.1：8087。那么在33版下，autoproxy实际上就是在用https连接本地端口了，对吗？然后数据包转交给goa后，goa使用我设定的http继续将”数据包“转发给gae--问题就在这里，这时goa从本地端口转发给gae的是一个什么样的数据包？我现在的理解是：这个数据包（加了引号的）其实已经是一个https加密过的数据包了，它不是由goa加密打包的数据包，而是由firefox33的新功能加密打包的一个https的数据包，goa只是负责将这个前面已经被https加密过的数据包用http协议继续向前传递，但无论如何，对一个数据包的整个网络传输过程来说，从firefox的浏览器客户端一直到gae（再后面的先不去管它了），实际上就变成了一个全程的https传递的过程。 如果我上述的理解没错，那么在上面这种情况下，等同于我在goa中设定所有的代理走https而不是http。所以才会造成我现在观察到的”代理缓慢“的现象。这样应该是可以解释的通的吧？而且我现在在同一台机器，同样的goa，同样的autoproxy扩展及规则下，分别使用firefox32和33，代理的效果的确是有明显的区别的。所以我的结论是，笼统点儿说，firefox33引入的这个特性其实还是有影响的。如果我的理解有问题，请继续指教。 ”图示“一下我的理解： firefox32: http的url：[http]data[http]-->goa-->[http][http]data[http][http]-->gae https的url: [https]data[https]-->goa-->[http][https]data[https][http]-->gae firefox33: http的url：[https]data[https]-->goa-->[http][https]data[https][http]-->gae https的url: [https]data[https]-->goa-->[http][https]data[https][http]-->gae 从传送的数据包的大小来说，是不是firefox33其实就变成了强制全程https了？ |
|
|
|
22楼#
发布于：2014-10-18 09:53
大道有狐：先感谢你解释了”Support for connecting to HTTP proxy over HTTPS“这句话的含义。我明白你的意思了。从源码看 AutoProxy 0.4b2.2013051811是通过nsIProtocolProxyService.newProxyInfo来设置代理的 见chrome/content/proxy.js第62行 http://mxr.mozilla.org/mozilla-release/source/netwerk/base/src/nsProtocolProxyService.cpp#1180 只有在指定aType=https的前提下 才会通过https连接http http://mxr.mozilla.org/mozilla-release/ident?i=kProxyType_HTTPS 可以看到对于kProxyType_HTTPS这个字符串常量的引用只在PAC相关部分 http://mxr.mozilla.org/mozilla-release/source/netwerk/base/src/nsProtocolProxyService.cpp#931 http://mxr.mozilla.org/mozilla-release/source/netwerk/base/src/nsProtocolProxyService.cpp#678 ProcessPACString调用ExtractProxyInfo 所以说目前只能通过PAC指定http over https 而AutoProxy 0.4b2.2013051811只区分http、socks、socks4、direct这4种 chrome/content/proxy.js第40行、第96行 所以通过autoproxy设置的代理应该仍然是通过http连接的 goagent的工作方式略复杂 在goagent到gae部分用它自己的编码加密/混淆了请求/响应 另外它本身还有一个mitm代理用来劫持原本通过http代理访问https地址时应该使用的connect方式 不论32、33，请求都应该大致为 http的url：-[GET/POST/HEAD等，明文]->goagent-[编码之后，http或https]->gae-[http，明文]->目标 https的url: -[CONNECT，密文]->build-in_mitm_proxy-[GET/POST等，明文]->goagent-[编码之后，http或https]->gae-[https，密文]->目标 有点晕…… 可能有点小错 总之 通过https连接到一个正常的http代理也只会新增加密浏览器到http代理这一段 http代理到目标服务器的部分和之前一致 |
|
|
|
23楼#
发布于：2014-10-18 10:39
aaaa007cn：janus本质上就是个spdy代理嘛这里有讨论 https://bugzilla.mozilla.org/show_bug.cgi?id=1047485 |
|
|
|
24楼#
发布于：2014-10-18 11:37
|
|
|
25楼#
发布于：2014-10-18 11:53
|
|
|
26楼#
发布于：2014-10-18 15:34
pcxfirefox：这里有讨论 https://bugzilla.mozilla.org/show_bug.cgi?id=1047485回到原帖之前搜的时候有搜到 这个标了DUPLICATE of bug 1079484 其实janus就是个spdy代理 而spdy还是跑在https之上的 参见 http://www.oschina.net/question/12_117516 所以1079484是Page Stalls with proxying HTTPS over HTTPS |
|
|
|
27楼#
发布于：2014-10-18 15:35
aaaa007cn：之前搜的时候有搜到是的 反正我也不懂这个 |
|
|
|
28楼#
发布于：2014-10-18 15:53
aaaa007cn：从源码看谢谢你的详尽回答，我基本上明白整个过程了。有时间的时候我会自己抓一下包自己确认整个流程到底是怎么个情况。 我这里现实的情况是：同样用autoproxy+goagent http的方式，的确存在在33版本上总是无法顺利、完整地打开页面的情况；而版本32下就非常顺畅。 稍后测试一下foxyproxy的在33下的表现如何。。。 |
|
|
|
29楼#
发布于：2014-10-18 15:58
teredarguiterep：connecting to HTTP proxy over HTTPS 是否需要代理支持？回到原帖是 如果代理服务器软件支持浏览器和代理之间走https的话 通常会需要额外设置证书、私钥 比如 http://wiki.squid-cache.org/Features/HTTPS#Encrypted_browser-Squid_connection、https://www.npmjs.org/package/spdyproxy |
|
|
