Wrong filename of pages with umlauts when using the REST-API

Follow

Sven Leichsenring

February 21, 2014 17:09

Hello,

when I am using the REST-API to automate my exports, I get filenames like this:

    scroll-export-v6-20140221_1701.pdf

if the page title contains umlauts.

I did the encoding check in Confluence and all seems to be fine.

How can ich prevent this behaviour?

Unfortunately it is not possible to customize the export filename at this time.

 

Thanks in advance,

Sven

 

0

• 

  Jens Rutschmann February 21, 2014 17:18

  Hi Sven,

  what client were you using to download the PDF file?

  A regular browser or  a tool like wget?

  We have some logic in there that determines the output filename based on the user agent string that the client sends. In your case it seems the exporter falls back to the safe replacement name because it thinks the used client can't deal with umlauts in the Content-Disposition header.

   

  Cheers,
  Jens

  0

  Comment actions Permalink
• 

  Sven Leichsenring February 24, 2014 14:08

  Hi Jens,

  you are right. I am using wget.

   

  Now I tried to fake the User-Agent-String with the option

  --user-agent="xxx"

  where xx ist a common User-Agent-String of Firefox(Win) and cURL-Library, but nothing works fine.

   

  BTW: The API-URL works fine with standard browsers like Firefox, Chrome and so on.

   

  Thanks in advance,

  Sven

  0

  Comment actions Permalink
• 

  Sven Leichsenring February 24, 2014 14:11

  I also tried to use an empty user agent string, so wget dosn't send the User-Agent header in its request, but it also did not work with umlauts.

  0

  Comment actions Permalink
• 

  Jens Rutschmann February 24, 2014 16:03

  Hi Sven,

  I double checked curl and wget and it seems they don't support filename specs as defined in RFC 6266 / RFC 5987

  We have a fallback in place for old Internet Explorer, Firefox and Safari version but everything else gets response headers like this:

       Content-Disposition: attachment;
                            filename="EURO rates";
                            filename*=utf-8''%e2%82%ac%20rates
  

  The "filename" value contains the ascii-only filename for legacy tools that you are getting: scroll-export-...pdf
  The "filename*" value in contrast contains the full name (with umlauts in your case) encoded according to RFC 5987

  Unfortunately wget and curl don't seem to support this standard. I also tried by only returning the utf8 filename but this made it even worse.

  So until wget or curl support this I fear there is no way to make it work.

  For curl I found a patch here: http://curl.haxx.se/mail/archive-2012-10/0039.html
  Until now it doesn't seem to have ended up in any official curl release.

   

  Hope that explains it,
  Jens

  0

  Comment actions Permalink
• 

  Sven Leichsenring February 26, 2014 10:53

  Hi Jens,

  what a pity. :-(

  so there is no solution at this time.

  Applying the curl patch exeeds my knowledge. And I'm not sure, if I would like that, if I were able to do that.

  How about an url parameter like "fallback=false" for the REST-API?

  I tried httrack but got even more problems (because of my lack of competence?).

   

  Cheers,

  Sven

   

  0

  Comment actions Permalink

Please sign in to leave a comment.