The ViewAttachmentServlet method setResponseHeaders() does

final String codedName = JiraUrlCodec.encode(attachment.getFilename(), true);
response.setHeader("Content-Disposition", disposition + "; filename*=" + jiraEncoding + "''" + codedName + ";");

which results in a header that looks like

Content-Disposition: inline; filename*=UTF-8''A%20filename%20with%20spaces

The problem is that browsers appear to have pretty poor support for the standard on this. This judgment is based on some quick preliminary testing by myself that confirmed what is on this page of cross-browser compliance testing

In order of level of support it appears to go: Opera 10 is nearly perfect, Firefox 3.5 misses a few edge cases, and then a three-way fail-tie for Google Chrome, Safari 4, and IE 8.

They fail in a lot of ways but the big problem is that JIRA is passing back an encoding character set and only Opera and Firefox can handle it. If we use the non-charset encoding format of

Content-Disposition: inline; filename="A filename with spaces"

Then Safari at least (I didn't try IE because I'm lazy) appears to do the right thing.

In terms of customer experience this means something as simple as filenames with spaces in it don't work the way they expect unless they are using Firefox. And even Firefox has bugs where it handles it differently depending on whether you click on the link directly or right-click and "Save Link As".

Obviously we need more testing (I was only checking filenames with spaces, for instance), and some Selenium tests around all of this is needed, but if this is true then I don't see how including the encoding is terribly useful to our customers. It seems like a better approach might be to do browser sniffing and/or check the filename encoding and only send an encoding if it's non-ASCII. Essentially something like what Chris Owen suggests in CONF-2487 which is a Confluence bug report about the same kind of thing.