How to make attachments with international file names work?
Asked by Candid Dauth _K15t_:

Hey there,

we are running Confluence 3.5 standalone on an Ubuntu server. Apache forwards all requests on Port 80 to Confluence using mod_proxy_ajp, configured in an .htaccess file:

```
RewriteEngine On
RewriteRule ^(.*)$ ajp://127.0.0.1:8009/$1 [P]
```

Tomcat is correctly configured with URIEncoding="UTF-8" and the Postgres database also uses UTF-8.

Now I created a test page with the title "?ml??t--Test" and attach a file "?ml??t--Test.txt" to it. This is what happens:

1. When I click a link to the page, I land on the page http://wiki/pages/viewpage.action?pageId=16875630, as Confluence does not seem to put the page title in the URL when it contains special characters. The page is displayed correctly.
2. When I manually enter the URL as http://wiki/display/ds/%C3%9Cml%C3%A4%C3%BCt%E2%80%93Test (which the browser displays as http://wiki/display/ds/?ml??t--Test), the page is also displayed correctly.
3. The attachment filename is displayed correctly in the attachment list.
4. When I click the attachment, I land on the URL http://wiki/download/attachments/16875630/%C3%9Cml%C3%A4%C3%BCt%E2%80%93Test.txt (displayed by the browser as http://wiki/download/attachments/16875630/?ml??t--Test.txt). I receive an error "Page not found".
5. When I access an attachment without special characters in the name, everything works correctly.
6. Inside the database, both the page names and the attachment names are displayed correctly.
7. The Confluence encoding test also does not report any errors.

This does not make any sense to me, as the URL encoding seems to be correct (else it wouldn't be possitble to access the page).

When I run a local Confluence 3.5 installation (using atlas-debug), everything behaves the same, except that point 2 instead of point 4 gives me the "Page not found" error, so in that case, passing the attachment name in the URL works but passing the page name doesn't. Adding URIEncoding="UTF-8" to the server.xml does not change that (although I'm not quite sure if atlas-debug actually uses the settings from that file).

Strangely, we've got another server running Confluence 3.2.1_01, and there everything works.

All issues I can find that are related to this seem to be about Confluence 2. Is this a bug introduced in Confluence 3.5 or did I do anything wrong?

Cheers,  
Candid

**Update:**

I found out something new: I uploaded a file called "?.txt". When I clicked on the link inside Confluence, the file name was correctly encoded as "%c3%a4.txt" in the URL. When I accessed it using "%e4.txt" (the ISO-8859-1 representation), the attachment successfully opened!


Answers:
author: Candid Dauth _K15t_
body: I found the problem now. Our server is running Ubuntu 8.04 LTS, whose Apache version (2.2.8) is quite old, a lot has been changed since then (see [Changelog](http://www.apache.org/dist/httpd/CHANGES_2.2)).

I tried several versions through and found out that the first version where it works is 2.2.12. The important change is probably this:

```
  *) mod_rewrite: When evaluating a proxy rule in directory context, do
     escape the filename by default. PR 46428 [Joe Orton]
```


author: JamieA
body: In the conf/server.xml, in the \<Connector\> element do you have URIEncoding="UTF-8" ? This is on by default for the 8080 connector but probably not for the Ajp one. You could try it... I would have thought the ajp protocol handled this but worth a try.

Also, for the working confluence instance, is that configured to store attachments in the database or on the filesystem? Same question for the failing one...

comments: author: Candid Dauth _K15t_
body: All of the instances store attachments on the file system (which should not make a difference as they are stored by ID). Also, I already have the URIEncoding set on the Connector.


Tags: attachment

encoding