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
- 5.2.0 tests (default below)
- Firefox 28.0
- Chrome (34.0.1847.131 m)
- Internet Explorer
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
- (thus) the Jasper Servlets HTTP response header (
(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) toapplication/octet-stream;charset=UTF-8
- looking at the header responses of IE or FF one can clearly see that no
- either by letting the user-set it manually or better by determining it via heuristics (file extension, content parsing, ...)
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)
Pragma
: should have the same meaning likeCache-Control: Public
Content-Language
: shouldn't matter here I guess
checking potential HTTP request problems
- order of request header rows shouldn't matter
Accept
: problematic?- seems ok looking at the specs http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
Accept-Language
: shouldn't matterCookie
: content shouldn't matterProxy-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>
- putting it as well under
jasperserver/WEB-INF/web.xml
does not help either - some more details about this can be also found here:
- putting it as well under
using the Rest API (
.../jasperserver/rest/resource/...
) works in both FF and IEIE 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?