Bug 458992 - Report produced in report viewer lack extention and could not be opened properly in Chrome Web
Summary: Report produced in report viewer lack extention and could not be opened prope...
Status: NEW
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: BIRT (show other bugs)
Version: 4.3.2   Edit
Hardware: PC Windows 7
: P3 major (vote)
Target Milestone: ---   Edit
Assignee: Birt-ReportViewer CLA
QA Contact:
URL:
Whiteboard:
Keywords: greatbug
Depends on:
Blocks:
 
Reported: 2015-02-03 02:10 EST by Marek Cwynar CLA
Modified: 2015-02-04 02:02 EST (History)
1 user (show)

See Also:


Attachments
xls report example file (37.41 KB, application/octet-stream)
2015-02-03 02:10 EST, Marek Cwynar CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marek Cwynar CLA 2015-02-03 02:10:36 EST
Created attachment 250454 [details]
xls report example file

Files produced by birt viewer  3.7.0  and 4.3.2 lack extension
UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.93 Safari/537.36

Example URL:

Steps to reproduce the problem:
Problem concerns BIRT reports,produced by Birt viewer v 3.7.0 and 4.3.2 that are generated as Excel spreadsheet (but in xml format).
1. Generate report using xls format (e.g. using link like https://xyz/birt/run?__report=test.rptdesign&__format=XLS
2. Browser saves the file, but it has no extension (I attach sample file)

Yesterday (26.01.2015) when following these steps the file was being saved with xls extension.

It seems that problem concerns also MS Word format of the BIRT report.

What is the expected behavior?
The file should be saved with xls extension.

What went wrong?
Downloaded EXcel xml spreadsheet file has no extension.

Did this work before? Yes Yesterday and before.

Chrome version: 40.0.2214.93  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 16.0 r0

This works fine in Firefox

The google support refused to fix that problem claiming that extension should be provided in file name. See attachment
 

You will find attached example file
Below is responce form google support:
#6 bentid...@gmail.com
I found that including the extension in the file name resolved this issue for me.
Jan 28 (5 days ago) #7 asanka@chromium.org
Yeah. The filename suggested by Content-Disposition is going to be used as-is as long as it's safe to do so. If you specify a Content-Disposition header with a filename, you also need to specify the extension. If you leave out the extension, the browser is going to assume that that was intentional.

Content-Type derived extensions are only added to a filename under a very restricted set of circumstances.