I'll start work on this tonight/tomorrow. The exact case happened to be a user making a request to upload with a Content-Length: 5346718903213477 which was immediately rejected with a 412, but the content length was logged.
After discussion, we decided it's best (we've had this sort of issue more than once now in other areas) to change from logging what we think the bandwidth might have been to what we know it was. With the WSGI spec there is no way to get the actual bytes transferred, but we can make new counters of our own and wrap request/response bodies to increment those counters. The WSGI spec also doesn't allow for logging /after/ the response has been fully sent (or terminated prematurely); but with Eventlet we can get around that with a non-standard hook. Other WSGI implementations would end up with lesser outgoing bandwidth logged, but at least that's better than over-billing people. -- Bytes In and Bytes Out are incorrectly logged https://bugs.launchpad.net/bugs/613667 You received this bug notification because you are a member of Registry Administrators, which is subscribed to OpenStack Object Storage (swift). _______________________________________________ Mailing list: https://launchpad.net/~registry Post to : [email protected] Unsubscribe : https://launchpad.net/~registry More help : https://help.launchpad.net/ListHelp
