Unhandled http error while appending an html with script element #4126
Comments
|
Thanks for opening an issue. However, you can find support on stackoverflow.com or the jquery forums. |
|
Why was this report closed? |
HolgerJeromin
changed the title
|
I can't confirm your issue, this works as expected in my JS Bin: http://jsbin.com/laqumev/edit?html,js,console,output Something else must be going in your code. |
|
@mgol |
|
@HolgerJeromin Thank you, I can confirm it locally on a same-origin request. In the future, please try to prepare as small an example as possible, here without any event handlers and especially without @timmywil I think it's a valid issue, we shouldn't try to eval a valid error response. Let's reopen for a discussion. |
|
I see. Thank you @mgol for taking the time to make a test case. However, I'm not sure this is necessarily wrong. jQuery is appending a script tag. The content is actually HTML. Whether it's eval'd by jQuery or executed directly by the browser, you'd get the same error. Right? |
I am pretty sure no sane browser will try to interprete an 404 response of an script element as JavaScript. I wrote an php code which has an 404 error and an alert as content. This script is referenced direct via script-element and loaded with jQuery. So this alert should be fired twice. But the alert is only fired when loaded via jQuery. Updated testcase: http://www.katur.de/bug.php |
|
@timmywil We're not doing what the browser does. As @HolgerJeromin mentioned, if a browser hits an error page when downloading a script it will display an error message in the console but will not try to evaluate the error page as a script. Meanwhile, we invoke the converter even for error responses and the converter calls I think it's a bug we should fix. Moreover, if the 404 page returns something parseable as JavaScript this may influence the page behavior randomly. Granted, such a response is unlikely but possible so in edge cases, this bug may have important consequences. |
|
Yup, that makes sense. I guess the only way the browser would try to execute is if the response code did not match the response content. |
|
The HTML Standard requires an "ok status" as defined by Fetch to be "in the range 200 to 299, inclusive". |
|
In the case where we are trying to emulate script tags, it makes sense that we would match browser behavior and only execute responses that matched HTTP 2xx. Ideally, people wouldn't try to inject strings that are script tags and we've agonized about the problems these cause for years, including the synchronous execution issue. |
|
Discussed in the meeting. We'll likely limit the eval to 2xx responses. |
|
I wasn't sure about what changes were necessary and had been exploring extensions to ajax converter and dataFilter arguments, but in the end came to a much simpler conclusion: rather than relying upon them, we should update return jQuery.ajax( {
url: url,
// Make this explicit, since user can override this through ajaxSetup (#11264)
type: "GET",
dataType: "text",
cache: true,
async: false,
global: false,
"throws": true,
// Only evaluate the response if it is successful (gh-4126)
success: function( text ) { jQuery.globalEval( text ); }
} ); |
|
@gibson042 So simple and clever. Love it. |
|
@gibson042 Since you found out how to fix the issue, do you plan to prepare a PR? |
|
Gracias |
IE and iOS <10 XHR transport does not succeed on data: URIs Ref jquerygh-4243 Ref jquerygh-4126
Description
I have an application where the customers can load arbitrary HTML code which is then loaded into the DOM via jQuery.
A customer had a copy and paste error which linked to an non existing js file. This lead to an 404 but nevertheless jQuery pushes the return value (error HTML page) into a HTMLScriptElement text property. This leads to an exception:
Minimal test case
Put this HTML onto an webserver:
The text was updated successfully, but these errors were encountered: