Closed Bug 1085094 Opened 6 years ago Closed 6 years ago

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

Categories

(Web Compatibility :: Desktop, defect)

Firefox 33
x86
Windows 7
defect
Not set

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1083090

People

(Reporter: bill, Unassigned)

References

()

Details

(Keywords: regression, site-compat, Whiteboard: [country-us] [sitewait])

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.
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
Flags: needinfo?(bill)
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.
the tool that makes it easy to find the regression range is here:
http://mozilla.github.io/mozregression/
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
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.
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.
Blocks: 237623
Status: UNCONFIRMED → NEW
Component: Untriaged → Desktop
Ever confirmed: true
Flags: needinfo?(bill)
Product: Firefox → Tech Evangelism
Version: 33 Branch → Firefox 33
Sure, I'll report it to the bank and point them here. Thanks!
Status: NEW → ASSIGNED
Whiteboard: [country-us] [sitewait]
Is this fixed now thanks to bug 1088850 ?
Then marking as dup of Bug 1083090. Please reopen if I'm wrong.
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1083090
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?
Nikolaos: Do you have a public example ?
(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
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.
(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?
(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
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.
Flags: needinfo?(heikki)
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.
Flags: needinfo?(heikki)
> 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!
just for the record: 33.0.2 didn't contain a fix for the issue but 33.1 does.
(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.
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.