python-swiftclient

Surprising behaviour when object names have spaces

Bug #1670917 reported by wolever
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Object Storage (swift)
New
Undecided
Unassigned
python-swiftclient
New
Undecided
Unassigned

Bug Description

400 instead of 404 is returned when a key with a space that does not exist is requested.

For example:

> client.get_object("a b")
400 Bad Request
> client.set_object("a b", "foo")
200 OK
> client.get_object("a b")
200 OK
"foo"

Revision history for this message
clayg (clay-gerrard) wrote :

Context and timing lead me to believe this is related to lp bug #1670915

I haven't figured out yet which client supports an interface like the above...

Normally we hope the body of the 400 response would have the details needed to understand the error - ideally the client would expose that detail in an exception/error/return-value.

This is problematic in python-swiftclient's case because the first request to hit the error is acctually a pre-flight HEAD request :\

ubuntu@saio:~$ swift upload test test --object-name "a b"
Object HEAD failed: http://saio:8080/v1/AUTH_test/test/a%20b 400 Bad Request

You can dig around result['error'] all you want; the resp that builds the ClientException just doesn't have a body.

If you can get past that [1] we do expose some of the response body by default:

ubuntu@saio:~$ swift upload test test --object-name "a b"
Object PUT failed: http://saio:8080/v1/AUTH_test/test/a%20b 400 Bad Request [first 60 chars of response] Object/Container/Account name contains forbidden chars from

1. attached patch is probably a terrible idea

Revision history for this message
wolever (david-wolever) wrote :

You likely have more insight into the inner workings of Swift, so please feel free to ignore if I'm off base here, but this was slightly different from lp bug #1670915:

The "forbidden characters" are blocked on both GET and POST requests, but in this case:

1. POST is allowed
2. The error is `400 Bad Request Syntax`
3. A GET works after the object has been POSTed

Here's an example:

> cxn.get_object("container", "a b x")
…
ClientException: Object GET failed: https://host/v1/auth/container/a%20b%20x 400 Bad request syntax ('GET /v1/auth/container/a b x? HTTP/1.1')

With the body:
<head>
<title>Error response</title>
</head>
<body>
<h1>Error response</h1>
<p>Error code 400.
<p>Message: Bad request syntax ('GET /v1/auth/container/a b x? HTTP/1.1').
<p>Error code explanation: 400 = Bad request syntax or unsupported method.
</body>

Revision history for this message
clayg (clay-gerrard) wrote :

Interesting...

I couldn't find an invocation of swiftclient.client.Connection.get_object that would produce a result like that (using latest swiftclient and swift with name_check forbidden_chars = " " sort of configurations - hardly an exhaustive search). I find the error message curious tho? I agree if somehow the server managed to receive a request line like 'GET /v1/auth/container/a b x? HTTP/1.1' it very much should respond bad syntax [1]!

And I can reproduce that [2] - but not with swiftclient.client.Connection.get_object who very much wants to quote the path? I'm not even sure *requests* would let you get an unquoted path on the wire? I wonder if tcpdump could prove the client *is* sending the quoted url - the ClientException sure makes it look like it quoted!?

So what split brain'd madness is allowing that path to get to the python http server unquoted? Who is adding the bare query string param? Is this a bug between the client and the wire or a malevolent proxy between the wire and our eventlet.wsgi.server?

1. https://github.com/python/cpython/blob/6c6186da42bf0080f273b439f06d2135f94a16d5/Lib/BaseHTTPServer.py#L286
2. https://gist.github.com/clayg/2ae111dcc8aec459a6b3838853ddc43f

Revision history for this message
wolever (david-wolever) wrote :

Hmm… that is _very_ weird.

I'm beginning to suspect that my hosting provider may have a broken configuration (specifically, I suspect they've got a proxy or something which is prematurely decoding the URLs). I've opened a ticket with them to double check.

A quick trace into my code leads me to believe that the URL is correctly quoted by the time it gets to Requests.

If you can give me credentials to another Swift cluster I'd be happy to try and reproduce there.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.