1085094 - Firefox 33 gives "source file could not be read" error for .qfx file download

Status: RESOLVED DUPLICATE of bug 1083090

(Web Compatibility :: Site Reports, defect)

Description

[Bill Waldron]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Firefox/31.0
Build ID: 20141011074935

Steps to reproduce:

I click the "account download" link at my credit union (gtefinancial.org) in order to obtain a .qfx file of my recent transactions.


Actual results:

I receive a message that '*.QFX.part could not be saved, because the source file could not be read"


Expected results:

I should have obtained a .qfx file.

Note that this only started happening after I updated Firefox from version 31 ESR to 33.0. Both Chrome and IE are able to download the .qfx files properly; also, Firefox 33 has no problem with other files downloaded from that server (e.g., account statements in PDF format).

I searched Mozilla support for similar issues and tried all suggested solutions...but the problem remains -- even when I run v33 in safe mode and with a brand new profile.

I reverted to 31.2.0 ESR and I am once again able to complete the .qfx download successfully.

Comment 1

[Matthias Versen [:Matti]]

This download link is not public that makes it very difficult to do something here.
The only option that i see here is that you install a tool that downloads automatically different Firefox nightly versions that you have to test to find the first nightly Firefox version that contains the issue.
The result would be a list of changes to the Firefox source in the 24h between both nightly builds and we may be able to identify the change that causes this issue.

The whole process takes some time and I'm not sure if you want to do that.
Without doing this we can still hope that someone else reports the same underlying issue in a different bug report but he has a public URL to test.

Please tell me how do you want to proceed

Comment 2

[Bill Waldron]

Yes, I understand that having the problem with my financial institution (and a small one at that) means that others can't duplicate the bug. When I get a chance in the coming days, I will see if I can determine which is the first version that contains the issue and report back.

Comment 3

[Matthias Versen [:Matti]]

the tool that makes it easy to find the regression range is here:
http://mozilla.github.io/mozregression/

Comment 4

[Matthias Versen [:Matti]]

This could be the same underlying issue as bug 1083090.

Can you please download this Firefox builds, extract them into a folder, close all current Firefox windows (!) and start the extracted Firefox.exe and test your download ?
I expect that the first one works and the other one fails 

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/06/2014-06-16-03-02-03-mozilla-central/firefox-33.0a1.en-US.win32.zip

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/06/2014-06-17-03-02-03-mozilla-central/firefox-33.0a1.en-US.win32.zip

Comment 5

[Bill Waldron]

Wow. I just completed testing to see when the problem shows up when I saw your email. That is indeed what I determined. The problem doesn't occur with Firefox 33.0a1 nightly builds from 6/10 through 6/16. It is the 6/17 build where the problem starts.

Comment 6

[Matthias Versen [:Matti]]

The issue seems to be caused by the fix of bug 237623.
That means unfortunately that this is a bug that has to be fixed on the server side.....
bug 1083090#c8 explains the technical details for a different url but this issue should be the same.

Bill, could you try to contact the IT department of your bank ?
You can point them to this bug report and I or our http developer will explain the issue to them.

Comment 7

[Bill Waldron]

Sure, I'll report it to the bank and point them here. Thanks!

Comment 8

[Daniel Stenberg [:bagder]]

Is this fixed now thanks to bug 1088850 ?

Comment 9

[Kohei Yoshino [:kohei]]

Then marking as dup of Bug 1083090. Please reopen if I'm wrong.

Comment 10

[Nikolaos Kornaros]

I am still experiencing the issue with Firefox 33.0.2: I cannot download some PDFs and get the error message as described here, and from the change log I would have expected this to be fixed with this release.

Can we have some feedback on that? Do you need more info?

Comment 11

[Matthias Versen [:Matti]]

Nikolaos: Do you have a public example ?

Comment 12

[Nikolaos Kornaros]

(In reply to Matthias Versen [:Matti] from comment #11)
> Nikolaos: Do you have a public example ?

Yes: https://wwwnet1.state.nj.us/treasury/dpp/ebid/Buyer/GetDocument.aspx?DocId=110010&DocName=BiddersDataPacketV3.pdf&DocLoc=7

Comment 13

[hxs]

This is also buggin our server now. Our intranet's CRM PDF saving stopped working on this ff version.
I can access the server code but I really don't know how to fix this. The file size is correct in the header and whole file is sent with "echo" statement at once.

I'm glad other browsers still work.

Comment 14

[Daniel Stenberg [:bagder]]

(In reply to hxs from comment #13)
> This is also buggin our server now. Our intranet's CRM PDF saving stopped
> working on this ff version.
> I can access the server code but I really don't know how to fix this. The
> file size is correct in the header and whole file is sent with "echo"
> statement at once.

If that is indeed true, then we're talking about a different problem. Any chance you can give us a URL to a live server showing the problem or possibly a full protocol (suitably anonymized or with sensitive data removed) dump?

Comment 15

[hxs]

(In reply to Daniel Stenberg [:bagder] from comment #14)
> (In reply to hxs from comment #13)
> > This is also buggin our server now. Our intranet's CRM PDF saving stopped
> > working on this ff version.
> > I can access the server code but I really don't know how to fix this. The
> > file size is correct in the header and whole file is sent with "echo"
> > statement at once.
> 
> If that is indeed true, then we're talking about a different problem. Any
> chance you can give us a URL to a live server showing the problem or
> possibly a full protocol (suitably anonymized or with sensitive data
> removed) dump?


Hello, I cannot provide live server as we are behind firewalls, but I can try to provide as much details as I can.
If you have any suggestions for tools to use to get you more information from the communication between firefox and server, Please suggest me. 

Here an image of the the headers
https://www.dropbox.com/s/9gipobzg1lhvn0u/protocol.png?dl=0
Error on firefox (soryy, UI in Finnish) It says cannot read source.
https://www.dropbox.com/s/suma2omxnu8vdm0/errors.png?dl=0
And PHP code (tcpdf) used to output the file
https://www.dropbox.com/s/mfe80zjjzhchkzo/outputcode.png?dl=0

Comment 16

[Matthias Versen [:Matti]]

hxs: 
Do you still get the error with Firefox33.0.2 because that should contain a fix for this issue ?

>The file size is correct in the header and whole file is sent with "echo" statement at once.
Your server sends the content with gzip applied (as seen in response header) and the content-length have to match the size of the compressed data and not of the uncompressed data.
You can test that if you remove gzip from the accepted encodings in Firefox as test.
Open about:config and remove the gzip part in the network.http.accept-encoding option.

Comment 17

[hxs]

Yes, the error appears only after updating to 33.0.2.
I'm not sure what was my previous version. Can I see it from some log in ff profile folder?

This same thing also happens from the link in message #12 from Nikolaos.

Comment 18

[hxs]

> hxs: 

> >The file size is correct in the header and whole file is sent with "echo" statement at once.
> Your server sends the content with gzip applied (as seen in response header)
> and the content-length have to match the size of the compressed data and not
> of the uncompressed data.
> You can test that if you remove gzip from the accepted encodings in Firefox
> as test.
> Open about:config and remove the gzip part in the
> network.http.accept-encoding option.

I removed file size from pdf download header (from server code) and it works now. The problem was really the size mismatch between gzipped and original pdf file.
Thanks!

Comment 19

[Matthias Versen [:Matti]]

just for the record: 33.0.2 didn't contain a fix for the issue but 33.1 does.

Comment 20

[Bill Waldron]

(In reply to Matthias Versen [:Matti] from comment #19)
> just for the record: 33.0.2 didn't contain a fix for the issue but 33.1 does.

Indeed it does.