I created an issue for that just now: https://jira.atlassian.com/browse/CONF-27548

Gotcha. Has a new issue been created that I can keep tabs on in the meantime?

You are right, Justin. Unfortunately, we've become aware of this issue only shortly after 4.3.3 was released. Confluence 4.3.5 which will be out very soon addresses this problem and attachment links will work again as expected.

This "fix" broke all the links to attachments for filenames that had spaces in them. Internal to Confluence, it works fine, but if someone had a bookmark or external link straight to an attachment, the spaces in the filename had '+' signs in them instead of spaces in 4.3.2 and before. Now, in 4.3.3, those links receive a file not found error.

I believe this should be clarified in the Upgrade Notes at the very least. A better solution (IMO) would be to have a check to see if a filename with spaces exists when a link with '+' signs is used. Then it could redirect to the file or display an intermediate page saying that the link has changed.

Okay, we have been investigating this issue in detail and the problem can be caused indeed by any combination of web server in front + tomcat, which might lead to URL double decoding.

To be specific, Apache first decodes the URL, then passes the decoded URL to Tomcat where it gets decoded again. Example: The attachment "a+.pdf" is served url encoded by Confluence as "a%2B.pdf". When the user clicks on the link Apache picks it up, url decodes it to "a+.pdf", passes it to tomcat where it gets url decoded again to "a .pdf". Then of course, "a .pdf" cannot be found because this file does not exist.

Options like 'nocanon' in mod_proxy, or "JkOptions +ForwardURICompatUnparsed" in mod_jk forward the unparsed/undecoded URL to Tomcat which prevents the double decoding.

We are working on a fix for Confluence 4.3.3 so that it does not depend on special configurations in Apache in order to make attachments with plus signs work. In the mean time, please configure any server fronted by Tomcat to pass on the undecoded URL.

Adding "nocanon" to the ProxyPass rule (mod_proxy) fixes this issue.

[httpd.conf]
ProxyPass /wiki http:///almserver01:9090/wiki nocanon
ProxyPassReverse /wiki http:///almserver01:9090/wiki

The following statement is associated with the use of "nocanon": "... Note that [nocanon] may affect the security of your backend, as it removes the normal limited protection against URL-based attacks provided by the proxy." I guess that means to use it at your own risk.

http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#proxypass

Same problem here. We are using mod_proxy_ajp instead of mod_jk.
mod_proxy does not accept the "JkOptions +ForwardURICompatUnparsed" option.

Same configuration as @Chad Barnes describes and the problem still exists.

We have URIEncoding="UTF-8" specified and we are NOT using mod_jk. Still, cannot download a single attachment with '+' signs in the name.

We ARE using Apache as a URL rewrite engine. That is:

http://alm/wiki -> http://almserver01:9090/wiki

[httpd.conf]
ProxyPass /wiki http:///almserver01:9090/wiki
ProxyPassReverse /wiki http:///almserver01:9090/wiki

The attachment DOES NOT download when I browse using the rewrite URL (http://alm/wiki).
The attachment DOES download when I go directly to the tomcat URL (http://almserver001:9090/wiki).

So, my guess is this has something to do with Apache... but maybe not just mod_jk.

Please take a look at Configuring Tomcat's URI encoding. The problem is caused by the web server configuration, not Confluence itself. If you are using Apache httpd with mod_jk make sure you add the "JkOptions +ForwardURICompatUnparsed" directive.