GAppProxy2 二三事

版权声明: 允许非商业性转载，但转载时必须标明原作者 fcicq、原始链接 http://www.fcicq.net/wp/?p=935 及本声明。

0.99.9 这个版本接近于这个 Code Base 下偶能做到的极限.
仍然有几个小问题做的并不够好. 不过这些问题完全不影响使用就是了. 最近也没有修掉这些问题的计划.

1 第一次超时, 第二次 (Range) 请求成功问题
如果这个文件并没有超过文件大小的限制, Range 反而是多了一步.
而且 Range 的处理也不够恰当.

如果未来能做重构的话, 偶直接会去掉 urlfetch limit 方面的判断.
把 Range 请求和普通请求用同一种方法解决.

此外要说, 偶虽然会用 Python, 但仍然没有用到语言独有的特点.

2 Range = 下载软件?
这种事情偶只遇上过一次. 就是明明写着 0-1023 却返回了 1023 bytes.
代码中有专门的判断以修复这个问题. 代码倒是很烂的感觉.
判断应来多少 bytes, 实际来了多少 bytes, 本次来了多少 bytes.
就别管它是否是 206 了.

3 加密与提交问题
WallProxy 用了一种简单的异或加密法. 还自己写了一个类似 urlencode 一样的函数.
偶觉得这种方法实在太朴素, 太奇怪.

首先如果要符合正常的 http 模式的话, 大号 POST 请求肯定要用 multipart/form-data.
直接的 POST 是 application/octet-stream 类型, 但从来没有浏览器会直接用这种 Mine Type 提交.
稍微注意一点的就会发现这个请求有问题, 完全不是浏览器发出的.

最初, 在原版 GAppProxy 基础上用了 Base64 以避免 encoding 的问题, 但要损失 1/4 的上传限制.
后来有了这种方法:
request = cgi.parse_qs(self.request.body) for k in request: request[k] = request[k][-1]
(thanks to @hexieshe)

最终还是用 multipart 解决了这个问题.

关于异或加密的问题. 偶说, 按照 block 来做几次循环移位或者是交换, 然后再用一次 xor 效果都比现在这种好的多.
当然确实是因为条件所限无法在这一层上用强加密.

真的要加密, 那就 SSL. 这没什么可争的. 只是验证 SSL 证书的任务只能靠自己.
当然 GAE Python SDK 上传的时候有验证证书, 这块代码可以考虑拿来.

既然说到这里, 不生成自签名证书的原因也就清楚了. 还有一个 CNNIC ROOT / SSL 的问题, 这里不提.

—

GAppProxy2 的推荐用法.

Google 系列服务, 靠 hosts + HTTPS 绝对没问题.
无论是 ipv4 还是 ipv6 都是这样的, 没有 https 支持的, 再用, 偶不反对.
前两天有人说 encrypted.google.com 不行了. 你出去看一看, 它的 SSL 证书的主机名是 *.google.com.
只要再找一个同样的出来, 这事情就解决了.

如果你有留心的话, 会注意到 proxy 可以设置成 google 主站, 甚至是 ipv6.google.com.
同样的方法… 加上 pac 文件, 也算是一种可以用的方法.

Facebook 有 ipv6 了, 好不好使是另一回事, 偶暂时不管.
上篇文章写了一种用 ipv6 上 twitter 的方法. 这里不重提了. 原有的 ipv6 文章也更新过了, 可以去看.
dabr 什么的也不是不能用. 所以这个事情没必要说太多.

友情提示: 请注意文章的时效性与准确性, 作者不对文章的有效性负责.