Thanks so much - with your hints we finally got this working too!

THANK YOU STEFAN!

The link you gave contained the clue that I needed to solve my problem.

I am running a regular apache+tomcat setup.

All I had to do was add "JkOptions +ForwardURICompatUnparsed" to my apache config.

So thank you and goodbye to this issue

h1. YOU AND WE GOT IT!

Due to your hints concerning url encoding and an information from your own server we finally found the solution.

As we use JBoss application server with tomcat embedded we tried the following:

http://confluence.atlassian.com/display/DOC/Configuring+Tomcat%27s+URI+encoding

Configuring Tomcat's URI encoding

By default, Tomcat uses ISO-8859-1 character encoding when decoding URLs received from a browser. This can cause problems when Confluence's encoding is UTF-8, and you are using international characters in attachment or page names.

In the conf/server.xml insert

<Connector port="8080" URIEncoding="UTF-8"/>

This means it is not enough to tell JBoss to use UTF-8. You have to tell it tomcat inside also.

I propose that you publish your information concerning JBoss/tomcat bundle on a higher level.

Thank you guys.

Cheers,

Stefan

Hi Odinn and Stefan,

The best way to address these issues with web container and proxy configuration is to open a support ticket at http://support.atlassian.com/ . We have dedicated support engineers who are well equiped to analyze your configurations and situations to find a solution for you.

The original bug related to this issue was fixed in Confluence 2.2 and as you can see is not reproduceable on confluence.atlassian.com

Chris

Christopher, I also have the problem, with a configuration as I have commented earlier.

I suggest that you attach the server.xml that you have on confluence.atlassian.com, then we can compare with our own.

I repeated my test on your public demo wiki, uploaded my döner.jpg and edited and deleted it, and there it works: http://confluence.atlassian.com/pages/viewpage.action?pageId=62980823

Sorry: you're completely right. The thing is: we don't know why it works on your public demo system and not on others (as our systems). What is different?

Hi Stefan and Philipp,

We have many customers using international characters successfully in attachment filenames. You can successfully remove an attachment called "döner.jpg" if it is attached to a page on http://confluence.atlassian.com/ which is running Confluence 2.5.4

This was my comment on CONF-4860 :

This is likely to be a URL encoding issue which the encoding test does not cover. It would be best if you opened a support request at http://support.atlassian.com/ . Make sure you indicate which application server you are using, and if it is tomcat, please attach the conf/server.xml file from the tomcat installation.

Could you please follow this advice so that we can help you use your attachments with extended character sets successfully? It is likely that you have not correctly configured the HTTP connector to use the correct URL decoding.

Cheers,
Chris

I wonder how Attlassian can handle this issue as "fixed" ?! It seems that nothing is fixed at all. Dear Atlassians: please open this issue again. Your customers are worldwide and other languages have more characters then [a-z, A-Z] like ä, ö, ü, ß, ´, `, and so on .....

Same for us: exatly the same problem, the same hack we used to delete these "döner.jpg" like files. Why can't this be fixed and is even worse now?

It's me again:

Now we are going to set up Confluence 2.5.4, and as we recognize, this problem ist still alive:

a file like döner.jpg can be uploaded by user to a page. But deleting or editing the attachment is not possible. The action leads to the Info page with the hint
"You cannot view this page due to inherited restrictions.
Page level restrictions have been applied to a parent of the current page. These restrictions limit access to only certain certain user(s) or group(s) and apply to all pages in the hierarchy underneath the parent."

In former versions of Confluence we was able to help ourselfs by typing the correct filename in the address field of the browser.
Now that "hack" doesn't work anymore (unfortunately).