services/ convert_response error: assert mask.endswith('/*')



Cloud Services
Server: Sync
6 years ago
5 years ago


(Reporter: atoll, Assigned: rfkelly)


Firefox Tracking Flags

(Not tracked)


(Whiteboard: [qa+])


(2 attachments)



6 years ago
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/", line 495, in __call__
    return, start_response)
  File "/usr/lib/python2.6/site-packages/paste/", line 68, in __call__
    return self.application(environ, replacement_start_response)
  File "/usr/lib/python2.6/site-packages/webob/", line 147, in __call__
    resp = self.call_func(req, *args, **self.kwargs)
  File "/usr/lib/python2.6/site-packages/webob/", line 208, in call_func
    return self.func(req, *args, **kwargs)
  File "/usr/lib/python2.6/site-packages/services/", line 191, in __notified
    response = func(self, request)
  File "/usr/lib/python2.6/site-packages/services/", line 270, in __call__
    result = function(request, **params)
  File "/usr/lib/python2.6/site-packages/syncstorage/", line 107, in get_collections
    response = convert_response(request, collections)
  File "/usr/lib/python2.6/site-packages/services/", line 133, in convert_response
  File "/usr/lib/python2.6/site-packages/webob/", line 145, in first_match
    if self._match(mask, offer):
  File "/usr/lib/python2.6/site-packages/webob/", line 323, in _match
    assert mask.endswith('/*')
Whiteboard: [qa+]


6 years ago
Assignee: nobody → rkelly

Comment 1

5 years ago
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:

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
Attachment #679916 - Flags: review?(telliott)

Comment 2

5 years ago
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.
Attachment #679918 - Flags: review?(telliott)
Attachment #679916 - Flags: review?(telliott) → review+
Attachment #679918 - Flags: review?(telliott) → review+

Comment 3

5 years ago

Comment 4

5 years ago
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.
Last Resolved: 5 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.