This has only happened 4 times on wp-web03 since November 2011, with the same error each time. Still, we should try to catch this before it causes a stack trace. Perhaps there's a broken user-agent sending a bad Accept: header? 2012-03-14 00:49:38,310 ERROR [syncserver] 954853f44c23c635e981171a03bbf598 2012-03-14 00:49:38,310 ERROR [syncserver] Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/services/util.py", line 495, in __call__ return self.app(environ, start_response) File "/usr/lib/python2.6/site-packages/paste/translogger.py", line 68, in __call__ return self.application(environ, replacement_start_response) File "/usr/lib/python2.6/site-packages/webob/dec.py", line 147, in __call__ resp = self.call_func(req, *args, **self.kwargs) File "/usr/lib/python2.6/site-packages/webob/dec.py", line 208, in call_func return self.func(req, *args, **kwargs) File "/usr/lib/python2.6/site-packages/services/baseapp.py", line 191, in __notified response = func(self, request) File "/usr/lib/python2.6/site-packages/services/baseapp.py", line 270, in __call__ result = function(request, **params) File "/usr/lib/python2.6/site-packages/syncstorage/controller.py", line 107, in get_collections response = convert_response(request, collections) File "/usr/lib/python2.6/site-packages/services/util.py", line 133, in convert_response 'application/whoisi')) File "/usr/lib/python2.6/site-packages/webob/acceptparse.py", line 145, in first_match if self._match(mask, offer): File "/usr/lib/python2.6/site-packages/webob/acceptparse.py", line 323, in _match assert mask.endswith('/*') AssertionError
Created attachment 679916 [details] [diff] [review] patch to catch-and-ignore errors from bad accept header This is a bug in WebOb, I've filed a fix over there: https://github.com/Pylons/webob/pull/83 It's also pretty trivial to work around in our own code, patch attached. (Technically we should return a "406 Not Acceptable" or "400 Bad Request" here, but the current behaviour is to return JSON by default so I kept it at that) We should also investigate sync2.0 codebase for this behaviour
Created attachment 679918 [details] [diff] [review] sync2.0 patch to test for ths behaviour Yep, the same behaviour is present in sync2.0. It will be substantially messier to work around here, since the matching occurs deep down inside pyramid. Hopefully it will be resolved upstream in short order.
Committed for sync1.1, but I can't think of a clean workaround for this in sync2.0. The upstream patch has been accepted so hopefully a fixed version will be released before too long. Given that this will only affect malfunctioning clients, and only inasmuch as they get a 500 error response rather than a 406 error response, I think it's safe to close this out.