You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jclouds.apache.org by Jeremy Daggett <je...@gmail.com> on 2014/04/03 22:25:47 UTC
Swift Patch to Content-Type for 1.7.2
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
Re: Swift Patch to Content-Type for 1.7.2
Posted by Shrinand Javadekar <sh...@maginatics.com>.
Jeremy,
Thanks for surfacing this. I believe this header means that if the
content type is not set, the Swift cluster should try and determine
it. If the header is set, it will be a no-op. Is this correct? Will
there be any downsides of setting this header?
Also, the change itself may not be just the couple of lines. You
probably want to add some unit tests as well.
What does the jclouds-jenkins plugin do that not having the content
type breaks it?
-Shri
On Thu, Apr 3, 2014 at 1:25 PM, Jeremy Daggett <je...@gmail.com> 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
Re: Swift Patch to Content-Type for 1.7.2
Posted by Jeremy Daggett <je...@gmail.com>.
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 <ga...@apache.org> 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/
>
Re: Swift Patch to Content-Type for 1.7.2
Posted by Andrew Gaul <ga...@apache.org>.
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/