Search code examples
excelinternet-explorertomcathttp-headersjasperserver

Opening file content resource (Excel) of JasperReports Server / Tomcat with Internet Explorer displays binary data inline

  • Content-Type/Accept/MIME HTTP headers issue?
  • JasperReports Server (5.2.0) (update 2014-08-20/21: 5.5.0 & 5.6.0 alike)
  • running on Tomcat 7
  • clients tried
    • Internet Explorer
      • 5.2.0 tests (default below)
        • 9.0.8112.16421 64bit (default below)
        • 11.0.9600.17105 64bit
      • 5.5.0 tests (update 2014-08-20)
        • 8.0.7601.17514
        • 9.0.8112.16421
        • 10.0.9200.16384
    • Firefox 28.0
    • Chrome (34.0.1847.131 m)

If I navigate in the JasperReports Server Web GUI to my previously uploaded Inhaltsresource (content resource), a *.xlsx Excel document, it works well in Firefox and Chrome, by offering to save or open the file, but it fails in Internet Explorer, by displaying the files binary content in the tab :-(

I did quite some research, but could not find a definitive cause, although some points may point at the cause:

(more general observation:)

  • the IEs/Jasper GUIs sent HTTP request header (ACCEPT string) seems to be wrong/incomplete/IE-incompatible
    • (thus) the Jasper Servlets HTTP response header (Content-Type string) seems to be wrong/incomplete/IE-incompatible

(when thinking about this a little deeper:)

  • shouldn't the JasperServer itself (or the Tomcat as the container to a certain degree on delivery) try to determine the to-be-delivered content type?
    • either by letting the user-set it manually or better by determining it via heuristics (file extension, content parsing, ...)
      • this way it could also be stored along with the file (I would only do it if the user want's to override the result of the heuristically determined type)
    • since the filename or the URL already easily indicate that it is a *.xlsx file and the content starts with PK... it already strongly indicates that it really is a (ZIP-packed) Excel file
    • so I would see two basic ways this should work in general...
      • the request header (Jasper-delivered GUI page) should define the content type explicitely (maybe only, if it can't be easily determined by the response functionality itself)
      • (generally maybe more appropriate:) the response header (Jasper/Tomcat server logic) should set the requested, correct or estimated content-type explicitely
        • looking at the header responses of IE or FF one can clearly see that no Content-Type is set here, although the REST-API call further down has it set (and it works there) to application/octet-stream;charset=UTF-8

Here are details that I checked already:

  • ok: the HTTP response headers for FF and IE do not significantly differ to me (although the request headers are quite different) (see below), thus indicating some issue with the magic of result content detection (where FF and Chrome seem to be better in this case)

  • the HTTP Headers of IE and FF request/response cycles:

    • IE 9 (captured with onboard dev tools):

      • request header

        Anforderung        GET http://...:8080/jasperserver/fileview/fileview/....xlsx? HTTP/1.1
Accept             application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, */*
Accept-Language    de-DE
User-Agent         Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Win64; x64; Trident/5.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E)
UA-CPU             AMD64
Accept-Encoding    gzip, deflate
Host               ...:8080
Proxy-Connection   Keep-Alive
Cookie             userTimezone=Europe/Berlin; JSESSIONID=0FEF6E9F46EB2202A041A0A6F37B249A; userLocale=de_DE; treefoldersTree=1%7Copen%3B4%7Copen%3B5%7Copen%3B8%7Copen%3B; lastFolderUri=/...

      • response header

        Antwort             HTTP/1.0 200 OK
Server              Apache-Coyote/1.1
Cache-Control       no-store
Expires             Thu, 01 Jan 1970 01:00:00 CET
P3P                 CP="ALL" 
Pragma    
Content-Language    de-DE
Content-Length      453242
Date                Thu, 08 May 2014 10:54:46 GMT
X-Cache             MISS from ..some-proxy-host..
X-Cache-Lookup      MISS from ..some-proxy-host..:8080
Via                 1.1 ..some-proxy-host..:8080 (squid/2.7.STABLE8)
Connection          keep-alive
Proxy-Connection    keep-alive

    • FF (captured with HttpFox addon)

      • request header

        (Request-Zeile)    GET /jasperserver/fileview/fileview/....xlsx? HTTP/1.1
Host               viasaxinfo.list.smwa.sachsen.de:8080
User-Agent         Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0
Accept             text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language    de,en-US;q=0.7,en;q=0.3
Accept-Encoding    gzip, deflate
Referer            http://...:8080/jasperserver/flow.html?_flowId=searchFlow
Cookie             userLocale=de; userTimezone=Europe/Berlin; JSESSIONID=E3989F65A4198047DA87FBB7BB73ABBA; treefoldersTree=1%7Copen%3B4%7Copen%3B5%7Copen%3B8%7Copen%3B; lastFolderUri=/...
Connection         keep-alive

      • response header

        (Status-Zeile)    HTTP/1.0 200 OK
Server            Apache-Coyote/1.1
Cache-Control     no-store
Expires           Thu, 01 Jan 1970 01:00:00 CET
P3P               CP="ALL" 
Content-Language  de
Content-Length    453242
Date              Thu, 08 May 2014 11:00:48 GMT
X-Cache           MISS from ..some-proxy-host..
X-Cache-Lookup    MISS from ..some-proxy-host..:8080
Via               1.1 ..some-proxy-host..:8080 (squid/2.7.STABLE8)
Connection        keep-alive
Proxy-Connection  keep-alive

  • ok: the compatibility view in IE does not help it

  • checking potential HTTP response problems (which differ)

  • checking potential HTTP request problems

    • order of request header rows shouldn't matter
    • Accept: problematic?
    • Accept-Language: shouldn't matter
    • Cookie: content shouldn't matter
    • Proxy-Connection: disabling/enabling proxy settings did not change something

  • ok: MIME type setup in tomcat7/conf/web.xml

    <mime-mapping>
  <extension>xlsx</extension>
  <mime-type>application/vnd.openxmlformats-officedocument.spreadsheetml.sheet</mime-type>
</mime-mapping>

  • using the Rest API (.../jasperserver/rest/resource/...) works in both FF and IE

    • IE 9:

      • with fileData=true (brings up a dialog whether to open or save the file where opening works as expected)

        • HTTP request header

          Anforderung        GET http://...:8080/jasperserver/rest/resource/....xlsx?fileData=true HTTP/1.1
Accept             text/html, application/xhtml+xml, */*
Accept-Language    de-DE
User-Agent         Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
UA-CPU             AMD64
Accept-Encoding    gzip, deflate
Host               ...:8080
Proxy-Connection   Keep-Alive
Cookie             userTimezone=Europe/Berlin; userLocale=de_DE; JSESSIONID=1B91EC2172C438C51A551CB967A3148D; treefoldersTree=1%7Copen%3B4%7Copen%3B5%7Copen%3B7%7Copen%3B10%7Copen%3B; lastFolderUri=...; foldersPanelWidth=239

        • HTTP response header

          Antwort          HTTP/1.0 200 OK
Server           Apache-Coyote/1.1
Cache-Control    private
Expires          Thu, 01 Jan 1970 01:00:00 CET
P3P              CP="ALL" 
Content-Disposition    attachment; filename=....xlsx
Content-Type     application/octet-stream;charset=UTF-8
Date             Fri, 09 May 2014 12:44:05 GMT
X-Cache          MISS from LIST-SRV-PROXY03
X-Cache-Lookup   MISS from LIST-SRV-PROXY03:8080
Via              1.1 ...some-proxy-host...:8080 (squid/2.7.STABLE8)
Connection       close

      • without fileData=true returning the expected resource meta data XML (displayed inline)

        <resourceDescriptor name="....xlsx" wsType="contentResource" uriString="/....xlsx" isNew="false">
 <label><![CDATA[....xlsx]]></label>
 <creationDate>1399636098445</creationDate>
 <resourceProperty name="PROP_RESOURCE_TYPE">
   <value><![CDATA[com.jaspersoft.jasperserver.api.metadata.common.domain.ContentResource]]></value>
 </resourceProperty>
 <resourceProperty name="PROP_PARENT_FOLDER">
   <value><![CDATA[/...]]></value>
 </resourceProperty>
 <resourceProperty name="PROP_VERSION">
   <value><![CDATA[0]]></value>
 </resourceProperty>
 <resourceProperty name="PROP_SECURITY_PERMISSION_MASK">
   <value><![CDATA[1]]></value>
 </resourceProperty>
 <resourceProperty name="CONTENT_TYPE">
   <value><![CDATA[contentResource]]></value>
 </resourceProperty>
 <resourceProperty name="DATA_ATTACHMENT_ID">
   <value><![CDATA[/....xlsx]]></value>
 </resourceProperty>
</resourceDescriptor>

I spent quite some time on this, but neither googleing (I wonder why nobody else seems to have this issue although it looks very common to me) nor various debugging did help. Maybe I would have to play in detail with the related Jasper classes to debug further, but maybe somebody else had this issue as well or knows a solution?

Solution

  • it seems there is a manual workaround possible: http://community.jaspersoft.com/jasperreportsr-server/issues/3716#comment-808481

    we implemented a servlet filter class to try to set the Content-Disposition header of the response in the cases when we knew that the MIME type was wrongly set. As we knew that the response was flushed after being processed by the web service end point, we set the header BEFORE being processed as Content-Disposition: attachment; filename='filename.extension'. This turned out to work, and we were able to download the file with an appropriate file extension.

    but they also mention that it would work with a v5.6.0 although it did not in our tests (see comment above: Opening file content resource (Excel) of JasperReports Server / Tomcat with Internet Explorer displays binary data inline)

    v5.6.0, and apparently on this release the MIME type of the response was correctly set, so we finally get to a proper solution for our problem.