2

I am uploading a file as part of the change event of my input file control via AJAX and FormData. The $form variable is a jQuery reference to my form (if that wasn't obvious).

$.ajax(url, {
    contentType: false,
    data: new FormData($form[0]),
    method: "post",
    processData: false
}).fail(function(xhr, status, error) {
    console.log(xhr.responseText);
    console.log(status);
    console.log(error);
})

This works in IE, FF and Chrome when I test locally. Once the application is deployed to our QA environment it stops working ONLY in FF (50.1.0 64bit). I can see the POST in the network tab, but the circle to the left stays grey as if it's still pending.

FF Developer Tools Screenshot

The request does "fail" and call my function, but there isn't any interesting information provided (console.log output available in screenshot also).

I thought perhaps it could be a CORS issue, but fiddling around in about:config and installing the CORS Everywhere plug-in did not yield a change in results.

Notable differences between local testing and QA testing environments are that the QA environment is a load balanced SSL offloading configuration. The SSL certificate we use is a wildcard meaning it works for any site *.company.com. Testing locally is plain text.

I did try some of the suggestions made here, but to no avail.

The last thing I tried was using Fiddler to see what was happening between FF and the application server. When Fiddler is set to decrypt HTTPS traffic the process starts working (weird). When Fiddler is capturing but NOT decrypting HTTPS traffic it doesn't work (just as if Fiddler wasn't running). This leads me to believe it could be certificate related?

I'm looking for suggestions/ ideas on what could be the issue.

EDIT:

I've done further experimenting and determined that submitting an empty FormData will POST to the server:

$.ajax(url, {
    contentType: false,
    data: new FormData(),
    method: "post",
    processData: false
})

As will a FormData with some garbage text key/ value pair:

var d = new FormData();
d.append("key", "value");
$.ajax(url, {
    contentType: false,
    data: d,
    method: "post",
    processData: false
})

POSTing will also succeed when no file has yet been selected (FormData with empty File).

I have also determined that accessing the application over HTTP instead of HTTPS allows Firefox to start working again (although I still don't understand why). The failing combination seems to be HTTPS + file data. I also confirmed that xhr.status = 0 and xhr.readyState = 0 when the error callback is fired.

Using ProcMon I was able to determine that my request is always leaving Firefox and making it to our load balancer (where SSL is terminated), but never leaving the load balancer (no matching Apache log entry). This same configuration still works for IE and Chrome so I'm uncertain if Firefox is forming the requests in such a way that they are being rejected by the load balancing appliance (Cisco ACE).

Community
  • 1
  • 1
Kevin Seymour
  • 766
  • 9
  • 25
  • `I thought perhaps it could be a CORS issue` - so, is the request CROSS ORIGIN? If so, does the server respond with appropriate CORS headers? – Jaromanda X Dec 29 '16 at 13:53
  • So is the call making it to the server? If you make the call without the form data, does it work? helping you debug this will be pretty hard.... – epascarello Dec 29 '16 at 14:11
  • @Jaromanda X: The request is not CROSS ORIGIN. I only ended up there due to some hits I got searching for the issue before posting. – Kevin Seymour Dec 29 '16 at 14:15
  • and the code you posted is complete? anything "unusual" about the form data? – Jaromanda X Dec 29 '16 at 14:16
  • @epascarello: I do not think the call is making it to the server, no. I can try to make the call without the FormData (I will send {}) and see what happens. – Kevin Seymour Dec 29 '16 at 14:16
  • wait - are you "intercepting" a `submit` without using `preventDefault()` perhaps? – Jaromanda X Dec 29 '16 at 14:17
  • @JaromandaX: That is not the ENTIRE function, but other than a success callback there is nothing really missing. Like I said it works in IE and Chrome so if it were a code bug I'd think it would manifest in those browsers as well. – Kevin Seymour Dec 29 '16 at 14:17
  • @JaromandaX: I do have an event.preventDefault(), but I'm not submitting the form, I'm triggering on the change event of a form input. – Kevin Seymour Dec 29 '16 at 14:18
  • You'd be surprised at how differently things work between browsers like Chrome and Firefox (I don't regard IE as even a remote discussion point) – Jaromanda X Dec 29 '16 at 14:18
  • `triggering on the change event` - OK, well, I'm out of ideas - good luck – Jaromanda X Dec 29 '16 at 14:20
  • @epascarello: I tried as you suggested `data: {}, // new FormData($form[0]),` and got a response from the server - `415--Unsupported Media Type` which is expected based on my Spring configuration. – Kevin Seymour Dec 29 '16 at 14:46

1 Answers1

0

We've determined that the issue is the CISCO ACE appliance we have SSL terminating/ load balancing our application. Something is mangling the packet data and preventing the request from completing. Here is the article that references the issue and the settings to adjust.

Kevin Seymour
  • 766
  • 9
  • 25