DLO GET/HEAD does not work if manifest value contains a '?'
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Object Storage (swift) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
It is possible to create a DLO Manifest with a segments container containing a question mark inside. E.g.
curl -XPUT ... -H"x-object-
But if this DLO Object should be retrieved (GET or HEAD), a 404 (or incorrect 2xx) is returned.
The reason lies in the DLO Middleware: It unquotes the container [1], but does not quote it again when doing the container listing [2]. Because the path contains now an '?', the '?' is used as the path/query separator, and everything after the '?' is cutted. Thus the internal container listing request looks like this in the proxy log:
Apr 11 12:24:21 swift proxy-server: - - 11/Apr/
(be aware that the log line is quoted again)
This means the container listing is done on the container called "a" and not "a?container". If this container does not exist, a 404 is returned. If the container does exist, an incorrect 2xx response would be returned.
A similar problem arises, if the object prefix contains a '?' and a GET is performed. A 409 conflict is returned (if filesize > 0) and the traceback looks like:
Apr 11 13:54:20 swift proxy-server: - - 11/Apr/
Apr 11 13:54:20 swift proxy-server: ERROR: An error occurred while retrieving segments: #012Traceback (most recent call last):#012 File "/usr/lib/
[1] https:/
[2] https:/
description: | updated |
summary: |
- dlo does not work when segments container contains a '?' + DLO GET/HEAD does not work if manifest value contains a '?' |
description: | updated |
description: | updated |
Well, I guess we've at least stopped returning 500 since https:/ /bugs.launchpad .net/swift/ +bug/1598093 ... but things are downright hilariously bad!
> If the container does exist, an incorrect 2xx response would be returned.
You ain't kidding! If 'a' doesn't include any objects starting with 'prefix' at least we just send an empty 200. But if there *are* objects, it returns as much of the JSON-formatted *full* container listing as the sum of sizes from the prefix listing allows!