JIRA
  1. JIRA
  2. JRA-1738

Excel export over https doesn't work

    Details

    • Type: Bug Bug
    • Status: Closed (View Workflow)
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.2
    • Fix Version/s: 3.0 Pro Preview
    • Component/s: Import / Export
    • Labels:
      None
    • Environment:

      SIL FieldWorks server, Version: 2.0.2-#46
      Open Source Project / Non-profit License

      Description

      Clicking on Excel view gives the error message:

      Microsoft Excel cannot access the file 'https://sdev.sil.org/sdev/jira/secure/IssueNavigator.jspa?view=excel&tempMax=1000'. There are several possible reasons:

      ? The file name or path name does not exist.
      ? The file you're trying to open is being used by another program. Close the document in the other program, and try again.
      ? The name of the workbook you're trying to save is the same as the name of another document that is read-only. Try saving the workbook with a different name.

      1. atlassian-core-2.0.17.jar
        62 kB
        Anton Mazkovoi [Atlassian]
      2. EncodingFilter-old.class
        3 kB
        Anton Mazkovoi [Atlassian]
      3. JIRAEncodingFilter.class
        2 kB
        Anton Mazkovoi [Atlassian]

        Issue Links

          Activity

          Hide
          Ed Kenschaft added a comment -

          Is this the same problem mentioned in CORE-3?

          Show
          Ed Kenschaft added a comment - Is this the same problem mentioned in CORE-3?
          Hide
          Scott Farquhar [Atlassian] added a comment -

          I can access that URL with no problems - what browser and version of Excel are you using?

          I feel that it may be a problem with Excel not handling the SSL properly.

          Show
          Scott Farquhar [Atlassian] added a comment - I can access that URL with no problems - what browser and version of Excel are you using? I feel that it may be a problem with Excel not handling the SSL properly.
          Hide
          Scott Farquhar [Atlassian] added a comment -

          Closing as wont fix as this is not a JIRA bug.

          Show
          Scott Farquhar [Atlassian] added a comment - Closing as wont fix as this is not a JIRA bug.
          Hide
          Ed Kenschaft added a comment -

          FYI, it has something to do with our local server. I can generate the Excel file using Netscape, but not IE.

          Show
          Ed Kenschaft added a comment - FYI, it has something to do with our local server. I can generate the Excel file using Netscape, but not IE.
          Hide
          Ingomar Otter added a comment -

          We have the same problem.
          It works with Mozilla, but not with IE.
          Although this looks like an IE issue, can somebody please look into this? Must be something with the URL or Mime?
          I mean even our "tie folks" like Jira, but they get depressed when they can not use Excel.

          Show
          Ingomar Otter added a comment - We have the same problem. It works with Mozilla, but not with IE. Although this looks like an IE issue, can somebody please look into this? Must be something with the URL or Mime? I mean even our "tie folks" like Jira, but they get depressed when they can not use Excel.
          Hide
          Ingomar Otter added a comment -

          Alas, browser is IE 6 (current "patchlevel")

          Show
          Ingomar Otter added a comment - Alas, browser is IE 6 (current "patchlevel")
          Hide
          Jeff Turner added a comment -

          This thread:

          http://forum.java.sun.com/thread.jsp?forum=45&thread=233446

          claims that a workaround is to set a "Cache-control: max-age=0" header. Would anyone experiencing this bug in IE/Excel like to test this? Attached is a recompiled version of atlassian-jira/classes/com/atlassian/jira/web/filters/EncodingFilter.class

          If it works (or not) please let us know and we'll include it in JIRA.

          --Jeff

          Show
          Jeff Turner added a comment - This thread: http://forum.java.sun.com/thread.jsp?forum=45&thread=233446 claims that a workaround is to set a "Cache-control: max-age=0" header. Would anyone experiencing this bug in IE/Excel like to test this? Attached is a recompiled version of atlassian-jira/classes/com/atlassian/jira/web/filters/EncodingFilter.class If it works (or not) please let us know and we'll include it in JIRA. --Jeff
          Hide
          Ingomar Otter added a comment -

          Doesn't make a difference for us.
          I will do a HTTP protocol trace, to see what's going on.

          – Ingomar

          Show
          Ingomar Otter added a comment - Doesn't make a difference for us. I will do a HTTP protocol trace, to see what's going on. – Ingomar
          Hide
          Mike Benzi added a comment -

          There is a microsoft KB article about the bug
          http://support.microsoft.com/default.aspx?scid=kb;en-us;812935

          Here is an excerpt:
          >SYMPTOMS
          >When you try to open a Microsoft Office document or a PDF file by typing an HTTPS Uniform Resource Locator (URL) for the document on the Address bar in Internet Explorer 6 Service Pack 1 (SP1), the document may not open, and you may receive the following error message:
          >
          >Internet Explorer cannot download document.pdf from server
          >CAUSE
          >This issue may occur if any of the following conditions are true:
          The Do Not Save Encrypted Files check box is selected in Internet >Explorer 6.0 SP1.
          >or
          >The server sends the "Cache-Control: No Store" header.
          >or
          >The server sends the "Cache-Control: No Cache" header.

          The solution suggested is a patch which we have installed and it fixed the problem

          Show
          Mike Benzi added a comment - There is a microsoft KB article about the bug http://support.microsoft.com/default.aspx?scid=kb;en-us;812935 Here is an excerpt: >SYMPTOMS >When you try to open a Microsoft Office document or a PDF file by typing an HTTPS Uniform Resource Locator (URL) for the document on the Address bar in Internet Explorer 6 Service Pack 1 (SP1), the document may not open, and you may receive the following error message: > >Internet Explorer cannot download document.pdf from server >CAUSE >This issue may occur if any of the following conditions are true: The Do Not Save Encrypted Files check box is selected in Internet >Explorer 6.0 SP1. > or >The server sends the "Cache-Control: No Store" header. > or >The server sends the "Cache-Control: No Cache" header. The solution suggested is a patch which we have installed and it fixed the problem
          Hide
          Scott Farquhar [Atlassian] added a comment -

          Closing as wontfix, as this is a Microsoft issue.

          Show
          Scott Farquhar [Atlassian] added a comment - Closing as wontfix, as this is a Microsoft issue.
          Hide
          Jeff Turner added a comment -

          Adding 'with https' to summary

          Show
          Jeff Turner added a comment - Adding 'with https' to summary
          Hide
          Scott Farquhar [Atlassian] added a comment -

          Reopening due to this comment:

          Thanks for the reply. As I understand it, according to JIRA-1738, you see
          this as a Microsoft problem. Not surprisingly, Microsoft sees it as your
          problem. Here is a quote from their support site:

          The problem occurs if the server is using Secure Sockets Layer (SSL) and has
          added one or both of the following HTTP headers to the response message:

          Pragma: no-cache
          Cache-control: no-cache,max-age=0,must-revalidate

          CAUSE
          In order for Internet Explorer to open documents in Office (or any
          out-of-process, ActiveX document server), Internet Explorer must save the
          file to the local cache directory and ask the associated application to load
          the file by using IPersistFile::Load. If the file is not stored to disk,
          this operation fails.

          When Internet Explorer communicates with a secure Web site through SSL,
          Internet Explorer enforces any no-cache request. If the header or headers
          are present, Internet Explorer does not cache the file. Consequently, Office
          cannot open the file.

          RESOLUTION
          Web sites that want to allow this type of operation should remove the
          no-cache header or headers.

          Their explanation seems reasonable enough, in a
          Microsoft-our-problem-is-really-your-problem kind of way. I verified
          through a Tomcat dumper Valve that JIRA is indeed sending the following
          headers:

          Pragma=No-cache
          Cache-Control=no-cache

          So, is there any way we can disable the no-cache headers in JIRA?

          Bill

          Show
          Scott Farquhar [Atlassian] added a comment - Reopening due to this comment: Thanks for the reply. As I understand it, according to JIRA-1738, you see this as a Microsoft problem. Not surprisingly, Microsoft sees it as your problem. Here is a quote from their support site: The problem occurs if the server is using Secure Sockets Layer (SSL) and has added one or both of the following HTTP headers to the response message: Pragma: no-cache Cache-control: no-cache,max-age=0,must-revalidate CAUSE In order for Internet Explorer to open documents in Office (or any out-of-process, ActiveX document server), Internet Explorer must save the file to the local cache directory and ask the associated application to load the file by using IPersistFile::Load. If the file is not stored to disk, this operation fails. When Internet Explorer communicates with a secure Web site through SSL, Internet Explorer enforces any no-cache request. If the header or headers are present, Internet Explorer does not cache the file. Consequently, Office cannot open the file. RESOLUTION Web sites that want to allow this type of operation should remove the no-cache header or headers. Their explanation seems reasonable enough, in a Microsoft-our-problem-is-really-your-problem kind of way. I verified through a Tomcat dumper Valve that JIRA is indeed sending the following headers: Pragma=No-cache Cache-Control=no-cache So, is there any way we can disable the no-cache headers in JIRA? Bill
          Hide
          Bill Lear added a comment -

          Scott says this is difficult because "If we don't set the time to live to 0, then IE caches the page & doesn't reload it" (I assume that "time to live to 0" is the equivalent of sending the Pragma=no-cache, and Cache-Control=no-cache headers). I wonder, though, when serving attachments, if this could be disabled, as it is not the "page" I am concerned about (assuming by "page", Scott means a JIRA page and not the actual attachment).

          So, for example, the request URI of:

          /jira/secure/attachment/10057/SomeDoc.xls

          presumably could be handled by not sending the no-cache headers.

          This is a serious issue for our company: we must run under SSL, we must support IE users, and we must have access to attachments. For what it's worth, it seems to me that this is not the fault of JIRA, as it is clearly an issue with Microsoft doing something stupid (i.e., not recognizing the difference between caching, and writing to disk in place of more sensible inter-process communication). However, I do think it warrants some digging into, as if this cannot be resolved for us, it may jeapordize us being able to continue to use JIRA, which I think (and our whole team thinks) is a fine tool.

          Show
          Bill Lear added a comment - Scott says this is difficult because "If we don't set the time to live to 0, then IE caches the page & doesn't reload it" (I assume that "time to live to 0" is the equivalent of sending the Pragma=no-cache, and Cache-Control=no-cache headers). I wonder, though, when serving attachments, if this could be disabled, as it is not the "page" I am concerned about (assuming by "page", Scott means a JIRA page and not the actual attachment). So, for example, the request URI of: /jira/secure/attachment/10057/SomeDoc.xls presumably could be handled by not sending the no-cache headers. This is a serious issue for our company: we must run under SSL, we must support IE users, and we must have access to attachments. For what it's worth, it seems to me that this is not the fault of JIRA, as it is clearly an issue with Microsoft doing something stupid (i.e., not recognizing the difference between caching, and writing to disk in place of more sensible inter-process communication). However, I do think it warrants some digging into, as if this cannot be resolved for us, it may jeapordize us being able to continue to use JIRA, which I think (and our whole team thinks) is a fine tool.
          Hide
          Jason Schnell added a comment -

          This is also an issue for us as we have to run it under SSL and utilize the excel exports frequently... at least we did until the IE 6.0 SP 1 was released.

          Show
          Jason Schnell added a comment - This is also an issue for us as we have to run it under SSL and utilize the excel exports frequently... at least we did until the IE 6.0 SP 1 was released.
          Hide
          Selders added a comment -

          This is also an important issue for us as we run it under SSL as well and want to utilize the excel exports frequently. People are complaining about it. This is currently the number one complaint for us.

          As a hint...

          Would it be possible to add a (custom) filter to change the reponse headers just for this Excel view? And set the cache to expire in 5 seconds rather then immediately?

          Show
          Selders added a comment - This is also an important issue for us as we run it under SSL as well and want to utilize the excel exports frequently. People are complaining about it. This is currently the number one complaint for us. As a hint... Would it be possible to add a (custom) filter to change the reponse headers just for this Excel view? And set the cache to expire in 5 seconds rather then immediately?
          Hide
          Scott Farquhar [Atlassian] added a comment -

          It looks like it isn't just us setting the headers, it is also the container. We'll have to set them explicitly in the Excel jsp.

          Show
          Scott Farquhar [Atlassian] added a comment - It looks like it isn't just us setting the headers, it is also the container. We'll have to set them explicitly in the Excel jsp.
          Hide
          Kalyanaraman Venkatasubramaniyan added a comment -

          We at Visual WEB Solutions, Inc are a paid customer of Jira. We are currently considering moving to Enterprise to open it up for our customers.

          However, this issue has been painfully affecting our plans. I find it so odd that for over 4 months, it isn't being paid any attention. Most corporate users work with Excel all the time and this is a key feature.

          Can you please fix this in a hurry as I can't justify upgrading without giving him this function?

          Show
          Kalyanaraman Venkatasubramaniyan added a comment - We at Visual WEB Solutions, Inc are a paid customer of Jira. We are currently considering moving to Enterprise to open it up for our customers. However, this issue has been painfully affecting our plans. I find it so odd that for over 4 months, it isn't being paid any attention. Most corporate users work with Excel all the time and this is a key feature. Can you please fix this in a hurry as I can't justify upgrading without giving him this function?
          Hide
          Anton Mazkovoi [Atlassian] added a comment -

          Hi,

          NOTE: The fix is done against version 2.6.1 of JIRA. Please upgrade to that version before trying this fix.

          Could you please replace the WEB-INF/lib/atlassian-core-2.0.15.jar with the atlassian-core-2.0.17.jar attached to this issue. Also replace WEB-INF/classes/com/atlassian/jira/web/filters/JIRAEncodingFilter.class with JIRAEncodingFilter.class (NOT JIRAEncodingFilter-old.class) attached to this issue and restart JIRA.

          Please let us know if this fixes the problem.

          Show
          Anton Mazkovoi [Atlassian] added a comment - Hi, NOTE: The fix is done against version 2.6.1 of JIRA. Please upgrade to that version before trying this fix. Could you please replace the WEB-INF/lib/atlassian-core-2.0.15.jar with the atlassian-core-2.0.17.jar attached to this issue. Also replace WEB-INF/classes/com/atlassian/jira/web/filters/JIRAEncodingFilter.class with JIRAEncodingFilter.class (NOT JIRAEncodingFilter-old.class) attached to this issue and restart JIRA. Please let us know if this fixes the problem.
          Hide
          Selders added a comment -

          These patches have fixed the excel download support for windows users that use internet explorer. At least I use IE 6.0.28 on Windows NT.

          But downloading Excel reports with Mozilla & OpenOffice on Linux (which worked before) has stopped working after applying these patches.

          Mozilla attempts to save and start up with the oocalc program. No file is downloaded. The error message I get in an popup dialog in Mozilla is the following:

          /tmp/IssueNavigator-2.jspa could not be opened, because an unknown error occurred. Sorry about that. Try saving to disk first and then opening the file.

          Clicking OK cancels the whole download process.

          Show
          Selders added a comment - These patches have fixed the excel download support for windows users that use internet explorer. At least I use IE 6.0.28 on Windows NT. But downloading Excel reports with Mozilla & OpenOffice on Linux (which worked before) has stopped working after applying these patches. Mozilla attempts to save and start up with the oocalc program. No file is downloaded. The error message I get in an popup dialog in Mozilla is the following: /tmp/IssueNavigator-2.jspa could not be opened, because an unknown error occurred. Sorry about that. Try saving to disk first and then opening the file. Clicking OK cancels the whole download process.
          Hide
          Bill Lear added a comment -

          This is still broken under Tomcat 5.x. I enabled a dumper valve to check the headers. I moved the atlassian-core-2.0.15.jar out of the way and copied in atlassian-core-2.0.17.jar. I moved JIRAEncodingFilter.class and installed the new one. I restarted Tomcat. The dump shows the headers are still being set:

          2004-05-11 21:48:12 RequestDumperValve[Catalina]: header=Pragma=No-cache
          2004-05-11 21:48:12 RequestDumperValve[Catalina]: header=Cache-Control=no-cache

          Needless to say, the download does not work (this is for a Microsoft Word document, incidentally).

          We are getting frustrated here. I really do appreciate Atlassian's effort, but I have spent a lot of time pursuing this with nothing to show, and an annoyed VP of development poking me every week about getting this fixed.

          Show
          Bill Lear added a comment - This is still broken under Tomcat 5.x. I enabled a dumper valve to check the headers. I moved the atlassian-core-2.0.15.jar out of the way and copied in atlassian-core-2.0.17.jar. I moved JIRAEncodingFilter.class and installed the new one. I restarted Tomcat. The dump shows the headers are still being set: 2004-05-11 21:48:12 RequestDumperValve [Catalina] : header=Pragma=No-cache 2004-05-11 21:48:12 RequestDumperValve [Catalina] : header=Cache-Control=no-cache Needless to say, the download does not work (this is for a Microsoft Word document, incidentally). We are getting frustrated here. I really do appreciate Atlassian's effort, but I have spent a lot of time pursuing this with nothing to show, and an annoyed VP of development poking me every week about getting this fixed.
          Hide
          Anton Mazkovoi [Atlassian] added a comment -

          Bill,

          The fix was only meant to fix one URL - the excel export from Issue Navifator. Are you referring to downloading MS Word attachments over https?

          Show
          Anton Mazkovoi [Atlassian] added a comment - Bill, The fix was only meant to fix one URL - the excel export from Issue Navifator. Are you referring to downloading MS Word attachments over https?
          Hide
          Bill Lear added a comment -

          Yes. I was under the impression that this issue also covered the other problems with downloading under https. This is the issue into which Scott entered my concerns and to which he directed me for follow-up.

          Is there no fix in mind for the Microsoft attachment problem?

          Show
          Bill Lear added a comment - Yes. I was under the impression that this issue also covered the other problems with downloading under https. This is the issue into which Scott entered my concerns and to which he directed me for follow-up. Is there no fix in mind for the Microsoft attachment problem?
          Hide
          Bill Lear added a comment -

          By the way, this did not in fact fix the Excel download problem.
          I tried clicking on the Excel view and it failed. I checked the dump of the headers and the no-cache header is still being set.

          Show
          Bill Lear added a comment - By the way, this did not in fact fix the Excel download problem. I tried clicking on the Excel view and it failed. I checked the dump of the headers and the no-cache header is still being set.
          Hide
          Selders added a comment -

          I just have tested this issue once more with Internet Explorer 6.0028 on Windows 2000. I had no problems with downloading a MS word attachment over https. This was on a Jira system with the bugfix applied.

          After this fix Windows users are now able to download Excel reports over https as well. As described before there are only problems introduced for Linux users.

          For clarity: we use Jira 2.6.1/Tomcat/MySql on RedHat 9 as backend server, furthermore we use Apache 1.3.x web server running https as a proxy webserver.

          Show
          Selders added a comment - I just have tested this issue once more with Internet Explorer 6.0028 on Windows 2000. I had no problems with downloading a MS word attachment over https. This was on a Jira system with the bugfix applied. After this fix Windows users are now able to download Excel reports over https as well. As described before there are only problems introduced for Linux users. For clarity: we use Jira 2.6.1/Tomcat/MySql on RedHat 9 as backend server, furthermore we use Apache 1.3.x web server running https as a proxy webserver.
          Hide
          Keith Brophy added a comment -

          Bart,

          We have performed extensive testing of the patched files running on Mozilla (Linuz) and IE (Windows) with Tomcat 4.x and Tomcat 5.0.19 (HTTPS) - and we have been unable to replicate the issue you described for Mozilla on Linux once the patched files have been applied.

          Can you describe your desktop environment in greater detail? (Mozilla version, etc.)

          Is it possible to access Tomcat directly in order to remove the proxy server from the equation?

          Thanks

          Show
          Keith Brophy added a comment - Bart, We have performed extensive testing of the patched files running on Mozilla (Linuz) and IE (Windows) with Tomcat 4.x and Tomcat 5.0.19 (HTTPS) - and we have been unable to replicate the issue you described for Mozilla on Linux once the patched files have been applied. Can you describe your desktop environment in greater detail? (Mozilla version, etc.) Is it possible to access Tomcat directly in order to remove the proxy server from the equation? Thanks
          Hide
          Selders added a comment -

          Just have tested with latest Mozilla browser on Windows XP and that works. It also works on latest Linux Fedora with Netscape 7.0.1. So far it does not work when Mozilla is 1.3.1 on Redhat 9. It makes no difference to go to straight to tomcat or through the apache proxy. May be it is a problem with this specific version of Mozilla. I will do an upgrade somewhere this week.

          Based on these findings I must conclude that this issue is solved on your side. Our users are happy. For our linux users we have a good configuration now that will work. Thanks for the support.

          Show
          Selders added a comment - Just have tested with latest Mozilla browser on Windows XP and that works. It also works on latest Linux Fedora with Netscape 7.0.1. So far it does not work when Mozilla is 1.3.1 on Redhat 9. It makes no difference to go to straight to tomcat or through the apache proxy. May be it is a problem with this specific version of Mozilla. I will do an upgrade somewhere this week. Based on these findings I must conclude that this issue is solved on your side. Our users are happy. For our linux users we have a good configuration now that will work. Thanks for the support.
          Hide
          Anton Mazkovoi [Atlassian] added a comment -

          Resolving the issue.

          Bill, please let us know if it is working on your side.

          Show
          Anton Mazkovoi [Atlassian] added a comment - Resolving the issue. Bill, please let us know if it is working on your side.
          Hide
          Jonathan Costello [Atlassian] added a comment -

          We have applied the following configuration to our Jira environment's Apache server:

          <Location /jira>
              Header set Cache-Control "private, must-revalidate"
              Header unset Pragma
          </Location>
          
          <Location /jira/secure/attachment>
              Header unset Cache-Control
          </Location>
          

          I added the second <Location ...> section in order to maintain the headers which are currently set on attachments being delivered.

          This appears to be working with the correct behaviour.

          Show
          Jonathan Costello [Atlassian] added a comment - We have applied the following configuration to our Jira environment's Apache server: <Location /jira> Header set Cache-Control " private , must-revalidate" Header unset Pragma </Location> <Location /jira/secure/attachment> Header unset Cache-Control </Location> I added the second <Location ...> section in order to maintain the headers which are currently set on attachments being delivered. This appears to be working with the correct behaviour.
          Hide
          Jonathan Costello [Atlassian] added a comment -

          For the above comment refer to https://support.atlassian.com/browse/JSP-29635.

          Show
          Jonathan Costello [Atlassian] added a comment - For the above comment refer to https://support.atlassian.com/browse/JSP-29635 .

            People

            • Assignee:
              Anton Mazkovoi [Atlassian]
              Reporter:
              Ed Kenschaft
            • Votes:
              5 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: