dug...@188.com
unread,Jun 25, 2008, 10:36:27 AM6/25/08Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to GAppProxy
之前用GAE SDK 1.0, 总感觉fetch服务放在本地和真实GAE上效果不同, 后来想到GAE可能对基础代码做了修改.
于是今天下了一个1.1版SDK, 看了其中一些urlfetch实现的代码, 发现urlfetch对重定向做了自动处理, 比如302不会返回给应
用, 而是自动跳转, 相比之下, 我更喜欢1.0 SDK 中把是否重定向交给应用决定的方式. 另外, 我认为GAE这么实现也是违背HTTP协议
的, HTTP协议规定, 是否重定向, 用户有决定权, 而GAE却在这里掐断了这种可能性, 最终用户甚至不知道自己现在在哪, 因为
urlfetch没有提供重定向后新的位置信息.
此外从我的角度看, SDK 实现代码写的也并不很好, 源请求与重定位后的请求除了HTTP method外其他完全相同(这也导致了奇怪的GET方
法+POST数据), 而不会去添加重定向Response中可能的set-cookie信息. 直接后果是像Web登录这种基本的事情做不了了. 为
什么呢, 举个常见的登录实现做说明:
用户填写form --> 提交到/cgi-bin/login --> 验证通过, 服务器端创建Session, 将Session标识写入
set-cookie, 回复302, 重定向到一个起始页面 --> 浏览器登录成功
GAE在这个过程中会根据302指示自动重定向, 但不加载set-cookie设置的cookie信息, 服务端认为浏览器没有打开cookie,
登录无效, 并且set-cookie作为302的header, 也不会返回给用户, 最终登录失败.
这个问题, 我暂时还想不到修正的办法, 也许是不可能修正的. 而普通的Web登录实现不了, GAppProxy 不会成为一个完整的
Proxy.
这个只是SDK实现方式, 真实GAE用的我感觉还有不小的差异.