FineUploader CORS selectively working

Question

I have been working with FineUploader successfully, and had a requirement to save to a different subdomain - HTML code at example.com, endpoint.php at upload.example.com.

I have it working perfectly every time in Safari uploading several small files. Those same small files always upload on FireFox and Chrome on Mac (latest versions as of January 2014), but I only get success feedback selectively with FireFox and Chrome on Mac. It always has "Processing..." or a percentage "61%" although the file is on the server.

When I put the HTML code on upload.example.com, it works fine. I am using FineUploader custom build (commercial support) v4.2.2, and I have updated the backend endpoint.php for the preflight response, etc. The issue is that the POST request hangs indefinitely, no matter what the server is set to. I even created a fake JSON responder that did nothing but respond with the JSON success string.

...
else if ($method == "POST") {
    handleCorsRequest();
    header("Content-Type: text/plain");
    echo '{"success":true,"uuid":"99999a18-a6c3-456e-bd06-e492f8a290c0","uploadName":"image1.jpg"}';
}
...

I was thinking it possible that JSONP is required to read the response back, and without that FineUploader doesn't know what is going on. However, FineUploader doesn't send a callback field as far as I can tell.

Any ideas? Happy to clarify. Below is an example of the pre-flight request, response and POST that hangs indefinitely.

Ryan

REQUEST ACCORDING TO PROXY:
Referer: http://example.com/?folder=TestFolder&id=1051&jobname=Test
Cache-Control: no-cache
Connection: keep-alive
Origin: http://example.com
Accept-Language: en-US,en;q=0.8
Accept: */*
Content-Length: 51729
Host: upload.example.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.77 Safari/537.36
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryxBA8idxO6Luv7Ipc
Accept-Encoding: gzip,deflate,sdch
X-Requested-With: XMLHttpRequest

RESPONSE ACCORDING TO PROXY, RETURN CODE 200:
Date: Fri, 24 Jan 2014 19:14:38 GMT
Server: Apache
Content-Type: text/plain
Connection: Keep-Alive
MS-Author-Via: DAV
Access-Control-Allow-Origin: *
X-Powered-By: PHP/5.3.15
Content-Length: 88
Keep-Alive: timeout=15, max=99

RESPONSE TEXT ACCORDING TO PROXY:
{"success":true,"uuid":"f0365869-312b-4080-bc30-1792e24fe366","uploadName":"image1.jpg"}

POSTED DATA:
------WebKitFormBoundaryxBA8idxO6Luv7Ipc
Content-Disposition: form-data; name="qquuid"

f0365869-312b-4080-bc30-1792e24fe366
------WebKitFormBoundaryxBA8idxO6Luv7Ipc
Content-Disposition: form-data; name="qqfilename"

image1.jpg
------WebKitFormBoundaryxBA8idxO6Luv7Ipc
Content-Disposition: form-data; name="qqtotalfilesize"

51200
------WebKitFormBoundaryxBA8idxO6Luv7Ipc
Content-Disposition: form-data; name="qqfile"; filename="image1.jpg"
Content-Type: image/jpeg

{binary data}
------WebKitFormBoundaryxBA8idxO6Luv7Ipc--

If the request hangs, then your server is not providing any response, or possibly not a proper response. You'll need to show all request traffic, including your server's response. A proxy, like fiddler, will be required to gather that information. — Ray Nicholus, Jan 24 '14 at 16:48
@RayNicholus Thanks for the speedy response. I have a dummy endpoint.php I tested that does this for a POST: handleCorsRequest(); header("Content-Type: text/plain"); echo '{"success":true,"uuid":"99999a18-a6c3-456e-bd06-e492f8a290c0","uploadName":"image1.jpg"}'; This fools Safari, but only fools (succeeds) on FF/Chrome intermittently. I will try some proxying to see what I can gather, but considering Safari works 100% and FF/chrome 80-90% of the time, I can't think of anything other than JavaScript for it failing. — ryanm, Jan 24 '14 at 17:11
There is no JavaScript failure here. The request you posted above indicates an issue with the response, so the problem is server-side. — Ray Nicholus, Jan 24 '14 at 17:39
@RayNicholus Ray, good tip on the proxy. I'm using HTTPScoop. Using two files to the endpoint.php CORS config (I added Access-Control-Max-Age: 15 to OPTIONS response), I get back two code 200's. Front-end shows success on one and processing on the other, I'm in Chrome incognito. Both response texts are identical except UUID and fileName, both are text/plain responses. If it's not in JavaScript but it is receiving a proper response AND it works 100% of the time in Safari, then where could the problem be? Bugs in Chrome and FireFox? Thanks for your ideas, FineUploader is an awesome product. — ryanm, Jan 24 '14 at 18:03
Are you sending credentials? Then have you tried setting Access-Control-Allow-Origin to the origin of the request (obviously not a good idea for production) rather than "*"? Is `allowCredentials` turned on in Fine Uploader? — Mark Feltner, Jan 24 '14 at 18:10
Please show the details of a response, according to your proxy, for a failing/hanging request. Also include the request headers/details alongside this. — Ray Nicholus, Jan 24 '14 at 18:12
@MarkFeltner Mark, great idea. For FF/Chrome the specific origin and the allowcredentials (sendCredentials: true) did the trick! Now FF/Chrome/Safari all work. That is also somewhat odd, since I don't want/care about cookies or other auth data. Either way, THANK YOU. — ryanm, Jan 24 '14 at 18:40
If you don't want/care about cookies or auth data, there is still some potential issue with your setup. Setting sendCredentials to true should not have fixed your issue unless there is some issue with your server response. — Ray Nicholus, Jan 24 '14 at 18:58
@RayNicholus I agree, it doesn't make sense that would fix it. I've modified the text with the proxy version of the failed call to upload image1.jpg. — ryanm, Jan 24 '14 at 19:22
@RayNicholus The "failed" call returns 200. The front-end sometimes recognizes that as a success, other time it says "processing" and spins forever. — ryanm, Jan 24 '14 at 21:18
The status code is not the only piece of the puzzle when CORS is involved. Without the request and response headers, there isn't any way to determine what is going wrong. — Ray Nicholus, Jan 24 '14 at 21:21
@RayNicholus The request/response full headers are included in the body of the question - I updated it yesterday in case you want to observe further. Thanks! Ryan — ryanm, Jan 25 '14 at 22:31

score 0 · Accepted Answer · edited May 23 '17 at 12:28

0

Since it looks like you are sending credentials, set the Access-Control-Allow-Origin header to the origin of the request (obviously not a good idea for production) rather than '*'.

If you did not have sendCredentials set as true in Fine Uploader, then you could have a wildcard Access-Control-Allow-Origin.

According to MDN:

[...] when responding to a credentialed request, server must specify a domain, and cannot use wild carding. The above example would fail if the header was wildcarded as: Access-Control-Allow-Origin: *.

Also, sourced from this answer: CORS: Cannot use wildcard in Access-Control-Allow-Origin when credentials flag is true

edited May 23 '17 at 12:28

Community

1
1

answered Jan 24 '14 at 19:47

Mark Feltner

2,041
1
12
23

Thanks Mark, this fixed it. I am surprised that this solved the problem, since I know of no credentials that are required to be sent. The proxy indicates that a 200 code is being returned even without the origin settings being used, which in my mind indicates FineUploader or the browser is not correctly interpreting the response from the server. I'll be interested if Ray Nicholus has any more ideas, though I am finished now with the project so can't do detailed testing. Either way, glad to have a solution. Thanks! – ryanm Feb 05 '14 at 15:34

FineUploader CORS selectively working

1 Answers1

Linked