Thomas O'Dowd created CLOUDSTACK-3027:
-----------------------------------------
Summary: Object_Store_Refactor - Uploaded template S3 content-type
is not appropriate.
Key: CLOUDSTACK-3027
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3027
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Template
Environment: latest object_store branch on fedora 17
devcloud on same machine
Cloudian (for S3 services) on separate machine. (expect similar result with
other S3 object stores).
Reporter: Thomas O'Dowd
This bug is related to the object_store branch.
Steps:
1. setup S3 object storage (can be amazon)
2. Add S3 as secondary storage
3. Upload a new template (I uploaded "tinyLinux.vhd.gz") by giving a url on my
local network where I had it hosted.
4. The template will be uploaded to S3.
Next using s3cmd or other tool, have a look at the Content-Type of the object
that is stored by issuing either a HEAD or a GET request on that object.
Here is what I got when i captured the HEAD request using ngrep.
=================== HEAD request and response ===================
HEAD
/template/tmpl/2/201/201-2-f9a12429-7cf4-3df5-b81c-420f09c1bbcd/tinyLinux.vhd.gz
HTTP/1.1.
Host: hello.s3.cloudian.com:18080.
Accept-Encoding: identity.
Date: Mon, 17 Jun 2013 05:06:19 GMT.
Content-Length: 0.
Authorization: AWS 00d25034c817eeb8c095:g/S63k9LHeZfz73l+moWm7MJ7z0=.
User-Agent: Boto/2.9.4 (linux2).
.
##
T 10.181.164.132:18080 -> 10.181.164.198:50450 [AP]
HTTP/1.1 200 OK.
Date: Mon, 17 Jun 2013 05:06:19 GMT.
x-amz-request-id: A55A3220D70B11E2.
Last-Modified: Fri, 14 Jun 2013 07:05:27 GMT.
ETag: "5b5c3506aef231519d0434f9749c951d-5".
Content-Type: application/x-www-form-urlencoded; charset=utf-8.
Content-Length: 25712307.
=================== end of HEAD request and response =================
Notice in the HTTP response that the "Content-Type" header is set to
"application/x-www-form-urlencoded; charset=utf-8". This does not correctly
describe the template content type.
The Content-Type was set by the client (Cloudstack) in the "Multipart Upload
Initiate" request at the beginning of the upload and should be fixed at that
point. I haven't looked at the code but perhaps we need to set a header or add
another parameter when initiating the multipart upload.
Of course, this begs the question... well what is the correct content type? I
looked around to see if I could find one for .vhd files but with no luck.
Perhaps "application/octet-stream" or even "application/x-gzip" (as this
particular object is compressed).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira