Hi Andrew, Yes, I believe that would be the best default behavior. My understanding is that if the value is null, Swift/Cloud Files should set the content type accordingly on the server.
What I am concerned with right now is how S3 (or other) blobstores handle null. FWIW, I have consulted with other SDK authors and they *never* set a default content type on the client. This fix [1] that uses the "X-Determine-Content-Type" header appears to behave correctly based on my debug output. The blobstore tests could use some love here and I am working on a better test. @abayer Is there any way to fix this in the Jenkins plugin when upgrading that codebase to 1.7.2? I am not clear on how to proceed here, so insight is appreciated. Thanks! /jd [1] https://github.com/rackspace/jclouds/blob/fix-swift-content-type/apis/swift/src/main/java/org/jclouds/openstack/swift/blobstore/functions/BlobToObject.java On Thu, Apr 3, 2014 at 4:28 PM, Andrew Gaul <[email protected]> wrote: > Should we change the default of ContentMetadataBuilder.contentType from > "application/unknown" to null? I previously encountered this odd > default in https://github.com/jclouds/jclouds/pull/44 . Would this > allow CloudFiles to guess the content type or must we hint via the > header? > > On Thu, Apr 03, 2014 at 01:25:47PM -0700, Jeremy Daggett wrote: > > Hi all, > > > > I realize that this is cutting it close, but here is a 3 line change to > > Swift that I would like to include into the 1.7.2 release. > > > > When using BlobBuilder to create a Blob, down in the guts of > > ContentMetadataBuilder[1] sets the default content type to > > "application/unknown", which should not be assumed as per RFC 2616 [2]. > > For say, a CSS (or any other non-"application" type for that matter) > file > > that content type is forced. > > > > According to the HTTP/1.1 RFC [2] section 7.2.1, the last paragraph > states > > that it SHOULD be set, but the recipient MAY attempt to guess the content > > type. > > > > In OpenStack Object Storage, the content type is "Optional", so it should > > not just be assumed that it will be "application/unknown". That last > > paragraph of the RFC also states that if the content type remains unknown > > that it will be treated as "application/octet-stream" > > > > Swift/CloudFiles has an optional header [3] "X-Determine-Content-Type" if > > set to "True" will ensure that the server sets the content type. For > > environments, such as Cloud Files, that understand this header, it will > > handle setting the content type on the server [4]. > > > > I want to set this header in the ObjectToBlob [5] class to fix a known > > issue with the jclouds-jenkins plugin. I am really surprised that this > has > > not been reported in the past! > > > > The simple change is: > > > > Multimap<String, String> headers = from.getAllHeaders(); > > headers.put("X-Detect-Content-Type", "True"); > > > > [1] > > > https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/io/ContentMetadataBuilder.java#L36 > > [2] http://www.ietf.org/rfc/rfc2616.txt > > [3] > > > http://docs.openstack.org/api/openstack-object-storage/1.0/content/PUT_createOrReplaceObject_v1__account___container___object__storage_object_services.html > > [4] > > > http://docs.rackspace.com/files/api/v1/cf-releasenotes/content/Feb21.html > > [5] > > > https://github.com/jclouds/jclouds/blob/master/apis/swift/src/main/java/org/jclouds/openstack/swift/blobstore/functions/ObjectToBlob.java#L49 > > -- > Andrew Gaul > http://gaul.org/ >
