[
https://issues.apache.org/jira/browse/JCLOUDS-854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14381843#comment-14381843
]
Damiano Albani commented on JCLOUDS-854:
----------------------------------------
I've just checked what happens when fetching an existing blob with
"Content-Disposition: gzip" through jclouds.
In this case, the payload stream contains the _decompressed_ data and only the
{{ContentMetadata::contentLength()}} property reveals the size of the data that
traveled on the wire.
This behavior is not directly related to my proposal of transparently
_compressing_ blobs but it shows that jclouds (and other components at a lower
level) are already involved with compression.
> Support "transparent" HTTP compression
> --------------------------------------
>
> Key: JCLOUDS-854
> URL: https://issues.apache.org/jira/browse/JCLOUDS-854
> Project: jclouds
> Issue Type: Wish
> Components: jclouds-blobstore
> Reporter: Damiano Albani
> Labels: blob, blobstore
>
> Unless I missed it, I haven't found a high-level parameter telling jclouds to
> use HTTP compression when uploading blobs.
> Yet many (all?) blobstore providers support transparent GZIP compression
> through the HTTP {{Content-Disposition}} mechanism.
> Even better than a global toggle, it would be nice to have some kind of
> {{PutOptions.COMPRESS}} option that could be set on a per blob basis.
> I don't really how this feature could be implemented though.
> Should this compression job be handled by jclouds itself or be the
> responsibility of the underlying HTTP driver library?
> The OkHttp library already contains the capability to transparently compress
> HTTP requests for instance:
> https://github.com/square/okhttp/wiki/Interceptors#rewriting-requests
> But I'm not sure if Apache Http Components supports this as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
