cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas O'Dowd (JIRA)" <>
Subject [jira] [Commented] (CLOUDSTACK-3027) Object_Store_Refactor - Uploaded template S3 content-type is not appropriate.
Date Mon, 17 Jun 2013 05:49:20 GMT


Thomas O'Dowd commented on CLOUDSTACK-3027:

Here is the S3 Initiate Multipart Upload request that sets the Content-Type.

============== Initiate Multipart Upload Request =============
POST /template%2Ftmpl%2F2%2F201%2F201-2-f9a12429-7cf4-3df5-b81c-420f09c1bbcd%2FtinyLinux.vhd.gz?uploads
Authorization: AWS 00d25034c817eeb8c095:5P8Y2VM69TgAbixlZoXhAsNjAzI=.
x-amz-storage-class: REDUCED_REDUNDANCY.
Date: Fri, 14 Jun 2013 07:05:26 GMT.
User-Agent: aws-sdk-java/ Linux/2.6.32-5-686-bigmem Java_HotSpot(TM)_Client_VM/20.1-b02.
Content-Type: application/x-www-form-urlencoded; charset=utf-8.
Transfer-Encoding: chunked.
Connection: Keep-Alive.
============== end of Initiate Multipart Upload Request =============

> Object_Store_Refactor - Uploaded template S3 content-type is not appropriate.
> -----------------------------------------------------------------------------
>                 Key: CLOUDSTACK-3027
>                 URL:
>             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
> Host:
> 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 -> [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:

View raw message