User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0 Build ID: 20170407033514 Steps to reproduce: Please see Bug 1264016. I thought it was my banks fault but further testing leads me to believe it's not. Please see https://getsatisfaction.com/quickencommunity/topics/problem-downloading-my-bank-transactions-into-firefox?rfm=1&topic_submit=true Actual results: The downloaded Quicken file has a contect-type of text/xml. I believe because of the way you make the file a part file that after it gets renamed it has an extension of .xml. Quicken expects an extension of .qfx. I downloaded Quicken data using both IE and MS Edge. The response headers were also contect-type of text/xml yet that imported into Quicken just fine. If I save the file to disk it appears correct with an .ofx extension and I can click on it and it gets imported into Quicken. I just can't open it up using Quicken without getting an error in Quicken.
Created attachment 8855876 [details] Open Menu Here's results of testing I've done on a clean profile. 1. I went to my bank's online banking web site and downloaded my current checking account transactions. 2. The screen shot I attached shows my options. The file name ends in .qfx which is the proper extension for Quicken to process. Also notice that the file is marked as an XML file. This presumably is because the HTTP content-type is text/xml. 3. Before I open the file this is the part file in my Windows Temp Folder: QRUkEyKr.xml.part 4. I then open the file with QuickenWindow which is the friendly name for qw.exe. Quicken opens up with an error message. It's because the file being passed to Quicken in my Temp folder is: 4963b883-015b-febd-1a1e-ac101516aa77.qfx.xml. Quicken can't process .xml files. Downloading my banks transactions using IE and MS Edge also has their content-type as text/xml. Yet when I open the file Quicken opens up and processes the file as it should. No error messages. I'm assuming the file ends properly with .qfx. It appears that the part file ending in .xml is part of the problem. And why does the final file name end in qfx.xml. Fx got the qfx part from somewhere. Fx should have ended the name with .qfx.
REQUEST HEADERS --------------- POST /IRSVPTN_ENS/s.ssobto?dse_contextRoot=true& HTTP/1.1 Host: rolb.santanderbank.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate, br Referer: https://rolb.santanderbank.com/IRSVPTN_ENS/s.ssobto?dse_contextRoot=true& Content-Type: application/x-www-form-urlencoded Content-Length: 229 Cookie: deviceTokenCookie=PMV64zd7%2Ferxb8A%2BMVNq0fbO9zr%2F7FqnInj%2FcyttmGs8gXPsUqiPHPBsZhsfiYwrBXRcmNLH%2F37M%2Fo9TRQADCi%2FKWBsA%3D%3D; deviceTokenFSO=PMV64zd7%2Ferxb8A%2BMVNq0fbO9zr%2F7FqnInj%2FcyttmGs8gXPsUqiPHPBsZhsfiYwrBXRcmNLH%2F37M%2Fo9TRQADCi%2FKWBsA%3D%3D; UID=I1056612; utag_main=v_id:015aa917a563001fd11c2f26b6980104e003b00d00c48$_sn:39$_ss:0$_st:1491597163164$dc_visit:39$_pn:2%3Bexp-session$ses_id:1491595359208%3Bexp-session$dc_event:1%3Bexp-session$dc_region:us-east-1%3Bexp-session; byside_webcare_tuid=7tmvu99v6hdhxfn8x3dttpiajftqryjywd1afizmawbipkxnlr; C05_COB_JSESSIONID=0001W1Q0UDsgPZ0jePubONFieB3:16s2n3oeb; LSESSIONID=jLd1oqcd4ocldyyCKx8s0TkDo%2FuSpnTQV06xEXavFtPX08UvMMtz5cWlYGo%3D; ___so68361234=eyJsc2giOjExMzYzNzYxMzYsInNkIjpudWxsLCJlIjp7Im4iOjMsImEiOlt7IjI4Ijp0cnVlLCJzciI6Imh0dHBzOi8vcm9sYi5zYW50YW5kZXJiYW5rLmNvbS9UaGVtZS10aGVtZS9pbWcvaG9tZS5wbmcifSwiMjgiXSwicmlkIjowLjQ1MzMzMzI3Mjk0OTcyMjZ9fQ%3D%3D; NewUniversalCookie=AC1015CD029AD72E4AF40267#22.214.171.124#1491596195741#600000#1491595659741#64000#PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iSVNPLTg4NTktMSI/Pjxjb29raWU+PGRlZmluaXRpb25OYW1lPk5ld1VzZXJQYXNzd29yZENvb2tpZTwvZGVmaW5pdGlvbk5hbWU+PG5hbWU+R0FSWSBTSEFQSVJPIEo8L25hbWU+PHVzZXJuYW1lPlNIQVlOQVBVUFBZPC91c2VybmFtZT48dXNlcklEPkkxMDU2NjEyPC91c2VySUQ+PC9jb29raWU+#DESede/CBC/PKCS5Padding#v1#SovereignInternet#NOT_USED#SHA1withRSA#AuOqm5mkFkT0SFTueUfxplbuPAVQ1eciGadzXR6iLrvIHz/TTgk+gj+DNrf/qStZwDuNvMBCcEzhLg0mneEpqfE4fhxXpSPzBBoKRa7+fDY+GL+XHYa+kbUkCzHtu9qfGI5amaNbjJQbxZKRwu4OeD5Nfaa+CPrRpkqBRJ4brIk=; C06_COB_JSESSIONID=0001xl-n4qSwK7sfMt0JQFC0q5P:1bbfg1fie; C03_COB_JSESSIONID=0001i52n08ni20i3XI6EpEgDldq:16n62qj6b Connection: keep-alive Upgrade-Insecure-Requests: 1 RESPONSE HEADERS ---------------- HTTP/1.1 200 OK Date: Fri, 07 Apr 2017 20:06:48 GMT Access-Control-Max-Age: 1000 Access-Control-Allow-Headers: x-requested-with, Content-Type, origin, authorization, accept, client-security-token, Access-Control-Allow-Origin Content-Disposition: attachment; filename=4a06a797-015b-fd7c-42a0-ac101563aa77.qfx Cache-Control: x-xss-protection: 1; mode=block X-UA-Compatible: IE=EmulateIE8 Keep-Alive: timeout=5, max=191 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/xml <********************************************** Content-Language: es-ES
Ideally, this is something we should fix to ensure we are compatible with the behavior of other browsers, and with our own behavior when saving to disk. We're definitely appending a double extension when there isn't a need. Currently there isn't a team dedicated to handling bugs in this area of the code, but CC'ing Gijs in case he happens to have the time to take a look. Otherwise I can look into this in the future.
If you upload a quicken file (probably want to remove all data from it, might be able to just use an empty .qfx file) to http://mime.ritey.com/ , what mime type does that produce? (alternatively, check in the Windows registry what content-type is listed for .qfx files ) Separately, Basically, I *do* think it's your bank's fault - text/xml isn't the correct mimetype. The internet suggests it should be application/vnd.intu.qfx or application/x-qfx . Our behaviour is probably also still wrong. I expect it's a side-effect of the behaviour I described in comment 0 of https://bugzilla.mozilla.org/show_bug.cgi?id=1357818 , and how we use both the mimetype and the extension to try to get a mimetype object with handler app information. We prefer the mimetype, which I guess is what is (somehow) resulting in us using the wrong extension. I don't have time to dive into this further right now, though. :-(
(In reply to :Gijs from comment #4) > Separately, Oops, I was going to say: separately, I assume that you've checked in a clean profile that this isn't the result of any add-ons or settings you're using?
I did try with a Clean profile.
This is a P1 bug without an assignee. P1 are bugs which are being worked on for the current release cycle/iteration/sprint. If the bug is not assigned by Monday, 28 August, the bug's priority will be reset to '--'.
Since there isn't a team dedicated to handling bugs in this area of the code, it makes sense to avoid P1 until a bug is assigned.