domain-name-system – 某些AWS实例上的Google c2dm transient 401错误

前端之家收集整理的这篇文章主要介绍了domain-name-system – 某些AWS实例上的Google c2dm transient 401错误前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我们怎样才能弄清楚为什么当我们要求c2dm发送通知时,某些 AWS实例上的 Google c2dm推送服务会偶尔出现401错误

这是一个短暂的问题.所有AWS实例大部分都成功向Google c2dm发送HTTPS请求,有些实例在100%的时间内成功,有些实例偶尔获得401.所以我们不相信这是我们的c2dm注册或我们的通知代码(python)已经生产超过一年的问题. 401错误始于2012年5月16日.

相反,我们认为亚马逊基础设施中的某些东西,包括DNS缓存,可能会以某种方式涉及到这个问题.谷歌回复了我们的询问:

I’d look for something that could cause flaky communications. Try and see if you’re getting unusual numbers of corrupted or dropped packets on that machine’s network
adapter.

但是,我们没有看到任何“片状通信”的证据.出现问题时,实例上的cpu负载几乎为0,并且麻烦的机器上的以太网连接数平均低于没有问题的实例.

一个线索是401错误似乎发生在丛中(几次发生在彼此约4分钟内),并且这些丛通常间隔10到60分钟(尽管可能有几个小时没有错误).我们没有看到I / O错误或“片状通信”错误,只有来自Google c2dm的401错误.

serverfault post引导我们考虑AWS上的DNS缓存,因为它与Google c2dm服务提供的证书中主机名的SSL验证有关,但似乎我们使用的python 2.7 urllib2默认不验证主机.

另一个线索是我们使用“弹性IP”功能更改了显示问题的第一个Web实例的IP地址:相同的,连续运行的实例,只需使用新IP.那个例子在4天内取得了100%的成功,但此后又恢复了偶尔的401s.

我们能做些什么才能揭示这一点?

堆栈跟踪示例:

c2dm push error: HTTP Error 401: Unauthorized 
Traceback (most recent call last):
   File "/home/django/base/src/mmsite/push/models.py",line 262,in send_c2dm_message     
   response = urllib2.urlopen(request) # third try
   File "/usr/local/lib/python2.7/urllib2.py",line 126,in urlopen     
    return _opener.open(url,data,timeout)
   File "/usr/local/lib/python2.7/urllib2.py",line 400,in open     
    response = meth(req,response)
   File "/usr/local/lib/python2.7/urllib2.py",line 513,in http_response     'http',request,response,code,msg,hdrs)   
   File "/usr/local/lib/python2.7/urllib2.py",line 438,in error
     return self._call_chain(*args)   
     File "/usr/local/lib/python2.7/urllib2.py",line 372,in _call_chain
     result = func(*args)
   File "/usr/local/lib/python2.7/urllib2.py",line 521,in http_error_default
     raise HTTPError(req.get_full_url(),hdrs,fp)
 HTTPError: HTTP Error 401: Unauthorized

401回复中返回的示例HTTP标头:

'headers': [
    'Content-Type: text/html; charset=UTF-8\r\n','Date: Fri,25 May 2012 00:24:25 GMT\r\n','Expires: Fri,'Cache-Control: private,max-age=0\r\n','X-Content-Type-Options: nosniff\r\n','X-Frame-Options: SAMEORIGIN\r\n','X-XSS-Protection: 1; mode=block\r\n','Server: GSE\r\n','Connection: close\r\n']

编辑其他测试信息:

我们能够在开发网络上重现这种瞬态401.有时它有效,有时它有401.由于开发网络完全独立于AWS,这将删除我们考虑的有关AWS的所有变量,并且重视Google问题所在的理论.谷歌回答说他们会升级这个问题.

解决方法

这是通过更改auth密钥(一个自动进程通过URL请求到c2dm服务获取新密钥,然后将其立即放入我们的服务器端推送代码)来解决的.我们不愿意这样做,而关键是对大多数c2dm推送工作正常,但看起来有些谷歌服务器对密钥不满意,导致我们间歇性错误.自从一周前更改它以来,我们一直没有错误.
原文链接:https://www.f2er.com/html/229034.html

猜你在找的HTML相关文章