Wrong filename of pages with umlauts when using the REST-API
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
-
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 -
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
-
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 5987Unfortunately 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 -
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
Please sign in to leave a comment.
Comments
5 comments