Glance

Content-Type header must be octet stream

Bug #755912 reported by justinsb
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Glance
Fix Released
Medium
Jay Pipes
Glance 2011.2 "cactus"

Bug Description

For an image upload via POST, the content-type header must be application/octet-stream, but this is not very clear from the documentation (the content-type seems to be related to image-download, not upload). It also looks like exceptions are not being handled properly, so the error message returned to the HTTP caller was not very clear...

curl --verbose --upload-file images -X POST "http://192.168.1.230:9292/images"
* About to connect() to 192.168.1.230 port 9292 (#0)
* Trying 192.168.1.230... connected
* Connected to 192.168.1.230 (192.168.1.230) port 9292 (#0)
> POST /images HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15
> Host: 192.168.1.230:9292
> Accept: */*
> Content-Length: 8577351680
> Expect: 100-continue
>
< HTTP/1.1 400 Bad Request
< Content-Type: text/html; charset=UTF-8
< Content-Length: 263
< Date: Sun, 10 Apr 2011 00:14:24 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 />
&lt;traceback object at 0x1918d40&gt;

 </body>

Related branches

lp:~jaypipes/glance/bug755912
Devin Carlen (community): Approve
Rick Harris (community): Approve
justinsb: Pending requested
Diff: 61 lines (+35/-1)
2 files modified
glance/server.py (+1/-1)
tests/functional/test_curl_api.py (+34/-0)
Revision history for this message
Jay Pipes (jaypipes) wrote :

On it. Thanks, Justin! :)

Changed in glance:
status: New → Confirmed
importance: Undecided → Medium
assignee: nobody → Jay Pipes (jaypipes)
milestone: none → cactus-rc
Revision history for this message
Jay Pipes (jaypipes) wrote :

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:

            raise exc_type(exc_traceback)

Revision history for this message
Jay Pipes (jaypipes) wrote :

Turns out that:

raise exc_type(exc_value)

works :)

Changed in glance:
status: Confirmed → In Progress
OpenStack Infra (hudson-openstack)
Changed in glance:
status: In Progress → Fix Committed
Thierry Carrez (ttx)
Changed in glance:
milestone: cactus-rc → 2011.2
status: Fix Committed → Fix Released
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.