Looking at the way that httplib2 catches exceptions, if there's for example a socket.timeout the conn object is not closed (https://code.google.com/p/httplib2/source/browse/python2/httplib2/__init__.py#1257) I suspect that might leave the conn object in a semi-broken state.
Since duplicity instantiates an httplib2 Http object and keeps it around (http://bazaar.launchpad.net/~duplicity- team/duplicity/0.6-series/view/head:/duplicity/backends/u1backend.py#L51), not creating a new one in the case of exceptions (http://bazaar.launchpad.net/~duplicity- team/duplicity/0.6-series/view/head:/duplicity/backends/u1backend.py#L80) I suspect that means a broken connection will be used on timeouts. A simple fix might be to throw away the Http object and create a new one. I'm going to give that a try (since I can reproduce the issue) and report back. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1161599 Title: Backup to Ubuntu one failed, after 5 attempts status 400 bad request To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/deja-dup/+bug/1161599/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
