jclouds-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Everett Toews <everett.to...@RACKSPACE.COM>
Subject RE: Setting Content-Disposition header containing Finnish alphabets å, ä or ö
Date Fri, 10 Jan 2014 21:06:31 GMT
Hi Kalle,

The problem isn't with Cloud Files after all. I reached out to a colleague with a deeper understanding
of this sort of encoding problem. Here's his answer.

"The heart of the problem lies in sun.net.NetworkClient.isASCIISuperset (read the comment
above the method):
The user’s system likely defaults file.encoding to UTF-8, which passes the checks in isASCIISuperset
but does not properly handle characters above 0x7F. What the client application needs to do
is explicitly set the protected String field sun.net.NetworkClient.encoding to “ISO8859_1”,
rather than allowing it to default to the file.encoding value. The field is static but protected,
so you should be able to create a class that overrides NetworkClient for the sole purpose
of applying this hack. For example, using the following class you could simply call NetworkClientHelper.applyStandardEncoding()
sometime before using jclouds.
public class NetworkClientHelper {
    private NetworkClientHelper() {
    public static void applyStandardEncoding() {
    private static class NetworkClientAccessor extends sun.net.NetworkClient {
        public static void setEncoding(String encoding) {
            sun.net.NetworkClient.encoding = encoding;

Another solution would be to use -Dfile.encoding=ISO8859_1 when starting your JVM but setting
file.encoding isn’t a good solution because it changes the default character set for the
entire application.

I did test this and confirm that it works. The returned Content-Disposition header appears
correctly and it appears correctly in the Cloud Control Panel too (in Chrome anyway).


From: Everett Toews [everett.toews@RACKSPACE.COM]
Sent: Wednesday, January 08, 2014 11:35 AM
To: <user@jclouds.apache.org>
Subject: Re: Setting Content-Disposition header containing Finnish      alphabets å, ä or

Thanks for that. I've reproduced the error and am reaching out to the Cloud Files team to
see if they can help.


On Jan 8, 2014, at 12:24 AM, Kalle Malin wrote:

> Hi Everett,
> I added my simple test case in the Gist
> https://gist.github.com/kallem/8312620
> - Kalle -
> ________________________________________
> Lähettäjä: Everett Toews [everett.toews@RACKSPACE.COM]
> Lähetetty: 7. tammikuuta 2014 18:36
> Vastaanottaja: <user@jclouds.apache.org>
> Aihe: Re: Setting Content-Disposition header containing Finnish         alphabets å,
ä or ö
> Hi Kalle,
> This could be a bit of a gnarly issue. It would really help to know exactly the code
you're running. Do you have a small Java application that reproduces this problem?
> Something that I could run myself. You could share it with us as a gist[1] or pastie[2].
> Thanks,
> Everett
> [1] https://gist.github.com
> [2] http://pastie.org/
> On Jan 7, 2014, at 7:25 AM, Kalle Malin wrote:
>> I see the header malformed in the Rackspace console. If I debug code the blob seems
to always have the header non-malformed but when putting  in the cdn it gets malformed.
>> When blob is read back it contains the malformed header.
>> 2014-01-07 15:23:16.190 org.jclouds.logging.slf4j.SLF4JLogger.logDebug:59 [main]
>> DEBUG: << Content-Disposition: attachment; filename="cöwböys änd åliens.png";
>> - Kalle -
>> ________________________________________
>> Lähettäjä: Andrew Phillips [andrewp@apache.org]
>> Lähetetty: 7. tammikuuta 2014 13:41
>> Vastaanottaja: user@jclouds.apache.org
>> Aihe: Re: VS: VS: Setting Content-Disposition header containing Finnish alphabets
å, ä or ö
>>> And the result for Content-Disposition "cöwböys änd åliens.png" in
>>> the Rackspace cdn Content-Disposition is "cöwböys änd åliens.png".
>> Are you seeing the malformed version of the disposition in the
>> Rackspace console? Or is this reported by jclouds somehow?
>> Could you try to *read* the blob back using jclouds and see what
>> Rackspace sends back? That should also be in the logs...
>> Regards
>> ap

View raw message