Jquery: jQuery.ajax: make `dataType: "script"` not execute scripts on unsuccessful HTTP status in 3.5.x

[redfox05]

Description

Bug Report
When doing an ajax request for a non-existing javascript script file, when used with dataType script, instead of failing and triggering the error handler function, it tries to evaluate whatever it gets back from the server, even if server returns a 404 with a HTML error page.

Expected Result

Error handler function is triggered.

Actual Result

Error handler is not triggered, and jQuery tries to evaluate the 404 error document as a javascript file.

This results in a Uncaught SyntaxError: Unexpected token '<'

This happens for both jQuery.ajax dataType script, and jQuery.getScript, which I imagine is because getScript seems to be just a shortcut for ajax with dataType set to script.

Link to test case

This issue was already logged previous and fixed for jQuery 4.0.0. in #4250 but this is still a problem in 3.4.1. Why was this not included as a fix for the 3.x.x versions?

The example issue can be see on StackOverflow, but this is a bug report, not a support issue.
https://stackoverflow.com/questions/61056023/jquery-ajax-unexpected-token-error-on-404-instead-of-normal-ajax-error-handler

Notes

If the fix has to stay with the 4.0.0 release, can we get a clear reason why, and perhaps suggestion for a workaround fix, or can we implement the fix ourselves?

[mgol]

Thanks for the report. It was scheduled for jQuery 4.0.0 as there may be some code out there that depends on executing scripts for 404 responses. That said, it does seem like an edge case & incorrect usage, really, so I'm open to considering backporting it.

We'll discuss this at the core meeting today.

[redfox05]

Thank you for the consideration. Is there any other way an error handler could catch this, or intercept using a pre-execution hook of some sort before the script execution? Then there could be more flexible if as you say, others rely on execution.

Although thinking again, a 404 script couldn't be executed if nothing was returned? Unless the error handling page was for some reason required to be parsed. But then still the error callback should be called before the execution stage or the success? From what I understood, success was only run on a 200 or 20x? So would have thought anything else would trigger error? At least some kind of callback somewhere I would have thought, as none of my error or success callbacks triggered.

Eagerly await the results of your meeting though, and if it does not go ahead, some suggestions on alternatives would be appreciated.

[mgol]

@redfox05 We've decided to backport the fix, thanks for making us re-evaluate this!

[redfox05]

Great thanks for the quick updates!

[redfox05]

@mgol Is there a rough date for 3.5.0? Is it days, weeks or months? Just a rough idea if possible will help for our planning and reminder to upgrade.

[mgol]

@redfox05 If nothing unexpected happens, the release should be out within a week.

[mgol]

Backported to 3.x-stable in da3dd85b63c4e3a6a768132c2a83a1a6eec24840.

[mgol]

jQuery 3.5.0 released: https://blog.jquery.com/2020/04/10/jquery-3-5-0-released/

[fschwahn]

FWIW, this change prevents us from updating to jQuery 3.5.x - so we seem to be the odd one out here. What we do is return HTTP 422 in case a validation fails on the server, and re-render the form with validation error messages via the returned script. We think da3dd85b63c4e3a6a768132c2a83a1a6eec24840 is responsible that this no longer works.

[mgol]

@fschwahn Many bug fixes change something around edge cases some people may depend on, unfortunately. You can work around this change by executing the script directly, something like:

$.ajax({
    method: 'GET',
    dataType: 'text',
    url: 'http://jquery.l/test/data/mock.php?action=errorWithScript&withScriptContentType',
}).catch(function (jqXHR) {
    return jqXHR.responseText;
}).then(function (data) {
    $.globalEval(data);
});