isErrorUploadResponse: successful response without success flag shouldn't fail

[mrjoelkemp]

I have a successful xhr response that doesn't have the success property and is still marked as an erroneous response – triggering the uploader's onError callback. I would expect this response to succeed and trigger onComplete or onAllComplete.

Should this line

fine-uploader/client/js/traditional/traditional.xhr.upload.handler.js

Line 79 in 178dcbf

return xhr.status !== 200 || !response.success || response.reset;

change: !response.success to be response.success === false?

The XHR:

The response:

[rnicholus]

Is this a response to an upload request?

[mrjoelkemp]

Yes, sorry. It's an upload request with form support being utilized. So there's an upload plus form data in the request.

[rnicholus]

The requirement has always been that a successful upload response must contain JSON in the payload with a success property with a value of true. This is only really necessary for IE9 and older (along with any other browser that does not support the File API) but has always been a requirement for all browsers for consistency.

The change you're suggesting seems reasonable, but it is indeed a breaking change and will have to wait for the next major release. (6.x).

[mrjoelkemp]

I see the documentation for what you're saying: http://docs.fineuploader.com/branch/master/endpoint_handlers/traditional.html. Thanks for clarifying.

I'm willing to close this since it's not a bug, unless you'd like to reword it into a feature request for the next major release.

Thanks a ton for the help.

[rnicholus]

Sure, I'll tag this appropriately.

In your endpoint, you'll definitely want to avoid returning a non-200 response for upload requests if you plan on supporting IE9 and older. Here's a snippet from our docs explaining why:

If the response code is not 200, and the size of the response is less than 512, or, apparently, sometimes, less than 256 bytes, IE replaces the response with a “friendly” error message. If you insist on returning responses with a status code other than 200, you can work around this by instructing IE users to uncheck the “show friendly HTTP error messages” setting or by padding the response JSON with whitespace as described

[rnicholus]

Moving this into the 6.0 milestone. With Microsoft dropping support for IE9 and older, I think it makes sense to focus even more on modern browsers going forward. Plan is to treat 2xx as successful, unless the JSON response indicates failure with success: false, just in case any existing integrations utilize this approach, or if integrators want to always return 200 but use the response to indicate failure for easier cross-browser support. IE9 and older will have to always return a 200 but can signal failure with a success property with a value of false in the JSON response.