Comment 6 for bug 1587815

Apparently we have here another manifestation of the issue [1]
with error handling during GET/HEAD operation on Swift's DLO.

In swift_trace.txt [2] it can be found that swiftclient, during
the delete operation, invokes HEAD on an object to remove:

DEBUG:urllib3.connectionpool:"HEAD /swift/v1/SwiftContainer/BIG HTTP/1.1" 500 0
INFO:swiftclient:REQ: curl -i http://10.200.153.31:8080/swift/v1/SwiftContainer/BIG -I -H "X-Auth-Token: 0654b266dc9a488d9a0aef04d9aa840e"
INFO:swiftclient:RESP STATUS: 500 Internal Server Error

In ceph-client.radosgw.gateway.log [3] we've got:
2016-06-01 09:35:51.988211 7ff5ee7c4700 1 ====== starting new request req=0x7ff61001f6b0 =====
2016-06-01 09:35:52.009023 7ff5ee7c4700 0 validated token: admin:admin expires: 1464777350
2016-06-01 09:35:52.014859 7ff5ee7c4700 0 could not get bucket info for bucket=SwiftContainer_segments
2016-06-01 09:35:52.014863 7ff5ee7c4700 0 ERROR: failed to handle user manifest ret=-2
2016-06-01 09:35:52.014873 7ff5ee7c4700 1 ====== req done req=0x7ff61001f6b0 http_status=200 ======

This means that RadosGW was not able to find the container
"SwiftContainer_segments" that is responsible for storing
segments of the "SwiftContainer/BIG" DLO. Most likely user
has deleted it previously. Unfortunately, RadosGW, in such
circumstances, generates wrong HTTP header. Apache, that is
used a front-end, signalizes that to client as 500 Internal
Server Error.

[1] https://bugs.launchpad.net/mos/+bug/1580937
[2] https://bugs.launchpad.net/mos/+bug/1587815/+attachment/4674281/+files/swift_trace.txt
[3] https://bugs.launchpad.net/mos/+bug/1587815/+attachment/4674342/+files/ceph-client.radosgw.gateway.log