This issue would appear to be fixed from IE 6.0 SP 1:

http://support.microsoft.com/default.aspx?scid=kb;en-us;812935

However, in order to resolve this issue for environments using older IE installations, the attached class will not apply the 'No-Cache' headers to a secure request to download an attachment:

../com/atlassian/jira/web/filters/JIRAEncodingFilter.class

Note: if you have forced JIRA to transmit everything over SSL, with a WEB-INF/web.xml entry like:

<security-constraint>
      <web-resource-collection>
        <web-resource-name>login</web-resource-name>
        <url-pattern>/</url-pattern>
      </web-resource-collection>
      <user-data-constraint>
        <transport-guarantee>CONFIDENTIAL</transport-guarantee>
      </user-data-constraint>
</security-constraint>

Then you will get this error even in 3.3.3 and above. Please restrict only the login pages, as specified in the documentation

Here is a tip: even if you wish to force JIRA to transmit everything over SSL, you can still workaround this IE bug. You need to stop Tomcat from sending the non-cache headers that prevent viewing of attachments on Internet Explorer on https. You can do so by adding the following valve in your context configuration file (ex. jira.xml), anywhere between <Context> and </Context>:

<Valve className="org.apache.catalina.authenticator.NonLoginAuthenticator"
disableProxyCaching="false" />

This is apparently not fixed by IE6sp1

We applied the JIRAEncodingFilter.class to JIRA 3.5.2 and found it did not fix the problem of opening attachments from IE. So we suggested users not to use IE. Do you have another patch for JIRA 3.5.2 ?

David,

That patch has been part of JIRA since 3.4. You shouldn't be patching JIRA 3.5.x with it (although it shouldn't hurt). https attachments in IE6 should be working. Please try the attachments on this public instance:

https://issues.apache.org/jira/browse/TAPESTRY-112

If you are having problems it's a different issue to this one - please raise an issue at https://support.atlassian.com

Cheers,
Jeff

I ran into this problem with JIRA 3.5.3 and IE6 SP2. I have forced JIRA to transmit everything over SSL.
And I can download attachments from https://issues.apache.org/jira/browse/TAPESTRY-112 with IE.
Only using of <Valve className="org.apache.catalina.authenticator.NonLoginAuthenticator" disableProxyCaching="false" /> helps to solve this problem.
Are there any other solutions?

Hi Iliya,
As far as I can tell this should be fixed in JIRA. The fact that you can download attachments from the issues.apache.org site is strange, because it should be configured just like your site. Are you doing anything out-of-the-ordinary in your JIRA installation? You are able to move ahead with the <Valve className="org.apache.catalina.authenticator.NonLoginAuthenticator" disableProxyCaching="false" /> workaround correct? It would be helpful if we could see what your JIRA instance is serving out, could you enable the RequestDumperValve in tomcat?

• Add the following to Tomcat's conf/server.xml just before the </Engine> tag is closed:

  <Valve className="org.apache.catalina.valves.RequestDumperValve"/>

• Then restart Tomcat. You should see a lot of information in logs/catalina.out file about each request and response.
• Could you request the attachment using IE and attach a zipped copy of the catalina.out file to this issue.

Thanks,
Dylan

Hi Dylan,
The thing is, tomcat adds "Cache-control: no-cache" to all responses received from the resources protected in web.xml. And we need to make all content in our installation of jira secure. So, I'm afraid, there is no solution except patching IE of our users or cutting cache headers by using disableProxyCaching="false". As far as I know, there is no easy way to make "/secure/attachment/* " open for http-requests and all other resources closed, because you must specify explicitly all resources you want to protect in web.xml. So you can simply protect "/* " (including "/secure/attachment/* " ) or protect manually all resources excluding "/secure/attachment/* ".

Hi Iliya,
Is there a problem with disableProxyCaching="false"? As far as I understand this should have tomcat stop adding the "Cache-control: no-cache" header, which is what we are after in your case. You are correct that you could specify all paths to include, if you wanted to go this route you could find most paths in the decorators.xml file. Can you successfully run with the disableProxyCaching="false" set?
Thanks,
Dylan

Well, I'm not sure that using of disableProxyCaching="false" wil not lead to caching of some jira pages in users browsers.

Hi Iliya,

Can you try modifying the web.xml file to have the following security-constraint section:

<security-constraint>
      <web-resource-collection>
        <web-resource-name>all</web-resource-name>
        <url-pattern>*.js</url-pattern>
          <url-pattern>*.jsp</url-pattern>
          <url-pattern>*.jspa</url-pattern>
          <url-pattern>*.css</url-pattern>
        <url-pattern>/browse/*</url-pattern>
      </web-resource-collection>
      <user-data-constraint>
        <transport-guarantee>CONFIDENTIAL</transport-guarantee>
      </user-data-constraint>
    </security-constraint>

With this in place, all URLs should be protected under HTTPS - except for the attachment downloads. Downloads can then be downloaded to the IE Temporay Internet files location before it can be opened by the external program.

Regards,
Keith

Thanks!
I think, it's the best solution.

SSL site-wide is really a necessity for our group. The best solution we've found is to put the following in conf/context.xml before the </Context> tag:

<Valve className="org.apache.catalina.authenticator.NonLoginAuthenticator"
disableProxyCaching="false" />

That'll disable proxy caching for all contexts, which is useful if you run JIRA and Confluence on the same machine.

We also had this error and we are running:
jira 3.6.5 (with security-constraints)
jboss 4.0.5GA
apache

After trying all of the solutions described, the one mentioned by Keith here (above):
http://jira.atlassian.com/browse/JRA-8179#action_55596

was the only one that actually worked.

I do have one comment though, could you guys put this security-constraint example in the default web.xml and comment it out with a good description?

I think that would save a lot of people some time..

This is handled by Microsoft as http://support.microsoft.com/default.aspx?scid=kb;en-us;812935

We investigated this further and got a reply from Microsoft, confirming that the bug has been fixed in IE6 SP1 (sic), however, it needs a registry entry to work correctly.

This is the registry entry that a MS-Support-Guy sent to us:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings
Create a DWORD entry named BypassSSLNoCacheCheck, set this to "1"

There is also another setting for HTTP without SSL, but I doubt anybody might be able to make use of this: BypassHTTPNoCacheCheck

The short version of the problem is, that IE does not save/cache SSL-content on disk, not even if you ask it to do so via "Save Link as" command. The registry patch enables the bugfix. I've not tried IE7 with regards to this problem.

IE6, IE7, IE8 still suffer from this problem with 3.13.4.

Using the all-except-attachments security constraint is a workaround, but that leaves attachments unencrypted.