Hmm, so it seems my fix to 729726, while fixing the bug, makes the traceback object be represented in the output like the above. When I revert that patch it shows this:
</html>jpipes@serialcoder:~/repos/glance/trunk$ curl --verbose --upload-file images -X POST -H "Expect: " "http://0.0.0.0:9292/images"
* About to connect() to 0.0.0.0 port 9292 (#0)
* Trying 0.0.0.0... connected
* Connected to 0.0.0.0 (0.0.0.0) port 9292 (#0)
> POST /images HTTP/1.1
> User-Agent: curl/7.21.0 (x86_64-pc-linux-gnu) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.18
> Host: 0.0.0.0:9292
> Accept: */*
> Content-Length: 4
>
< HTTP/1.1 400 Bad Request
< Content-Length: 268
< Content-Type: text/html; charset=UTF-8
< Date: Mon, 11 Apr 2011 18:21:41 GMT
<
<html>
<head>
<title>400 Bad Request</title>
</head>
<body>
<h1>400 Bad Request</h1>
The server could not comply with the request since it is either malformed or otherwise incorrect.<br /><br />
Content-Type must be application/octet-stream
</body>
* Connection #0 to host 0.0.0.0 left intact
* Closing connection #0
So, I'll look for a better way of raising a three-tuple of exception information than what I did, which was this:
Hmm, so it seems my fix to 729726, while fixing the bug, makes the traceback object be represented in the output like the above. When I revert that patch it shows this:
</html> jpipes@ serialcoder: ~/repos/ glance/ trunk$ curl --verbose --upload-file images -X POST -H "Expect: " "http:// 0.0.0.0: 9292/images" pc-linux- gnu) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.18 octet-stream
* About to connect() to 0.0.0.0 port 9292 (#0)
* Trying 0.0.0.0... connected
* Connected to 0.0.0.0 (0.0.0.0) port 9292 (#0)
> POST /images HTTP/1.1
> User-Agent: curl/7.21.0 (x86_64-
> Host: 0.0.0.0:9292
> Accept: */*
> Content-Length: 4
>
< HTTP/1.1 400 Bad Request
< Content-Length: 268
< Content-Type: text/html; charset=UTF-8
< Date: Mon, 11 Apr 2011 18:21:41 GMT
<
<html>
<head>
<title>400 Bad Request</title>
</head>
<body>
<h1>400 Bad Request</h1>
The server could not comply with the request since it is either malformed or otherwise incorrect.<br /><br />
Content-Type must be application/
</body>
* Connection #0 to host 0.0.0.0 left intact
* Closing connection #0
So, I'll look for a better way of raising a three-tuple of exception information than what I did, which was this:
raise exc_type( exc_traceback)