Skip to content

Conversation

@skrobinson
Copy link
Contributor

Summary

Fix for #4250.

Checklist

@timmywil timmywil changed the title Fix for #4250 Do not execute scripts for unsuccessful http responses #4250 May 6, 2019
@timmywil
Copy link
Member

timmywil commented May 6, 2019

I'd approve without the wip commit. Travis will run on PRs.

@mgol
Copy link
Member

mgol commented May 6, 2019

Don't we want converters to be applied for unsuccessful non-script responses?

@timmywil
Copy link
Member

timmywil commented May 6, 2019

Good point. This should be limited to scripts.

@skrobinson
Copy link
Contributor Author

Should converters be run on error responses? For text and html, probably yes. For scripts, no. What about json, jsonp, and xml?

@dmethvin
Copy link
Member

dmethvin commented May 7, 2019

I know of APIs that return non-200 status with JSON. The only case we want to prevent here is script.

@mgol
Copy link
Member

mgol commented May 7, 2019

I did some attempts in mgol@0cf3869 some time ago but I struggled with how to actually detect scripts. This is because a script may have dataType === "script" but it may also have none when it was determined to be a script via content-type matching.

@skrobinson
Copy link
Contributor Author

@dmethvin Good point. Should we consider APIs which intentionally return non-200 status scripts?

Is it correct to replace anything other than the default converter? My current patch would also replace any custom "text script" converter.

@mgol
Copy link
Member

mgol commented May 8, 2019

@skrobinson Returning data on non-200 responses definitely makes sense. Consider a JSON API that sends a 400 with JSON data describing an error in body; that's quite common. Scripts are special in that its response is not really just "converted" but executed as a script, that's why we want to avoid it in this specific example. I think that answers your question:

Is it correct to replace anything other than the default converter?

with: no, that's not correct. We need to stop applying converters for scripts only.

@skrobinson
Copy link
Contributor Author

Is it correct to replace anything other than the default converter?
with: no, that's not correct. We need to stop applying converters for scripts only.

Yes, I'm convinced about data. But, should we be careful not to disrupt a non-default "text script" converter? If the dev-user has defined a "text script" converter with ajaxSetup, should we still replace that converter with a noop?

@mgol
Copy link
Member

mgol commented May 8, 2019

@skrobinson A good question. I think I'm fine with ignoring user-provided script converters for failed HTTP status codes.

@skrobinson
Copy link
Contributor Author

@mgol I'm still learning the GH way and should have brought commit 3e3fc0d to your attention. It think this incorporates all current feeback. Please let me know about other edits to be done.

Copy link
Member

@mgol mgol left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like to see a test for a request without dataType but with a response with a JS Content-Type, plus maybe one for jsonp? You can incorporate a test from my attempt at mgol@0cf3869.

I also left one comment.

Other than that, this seems to work, nice job!

@skrobinson
Copy link
Contributor Author

skrobinson commented May 13, 2019 via email

@timmywil timmywil added this to the 4.0.0 milestone May 13, 2019
@mgol
Copy link
Member

mgol commented May 13, 2019

@skrobinson No problem, we're not in a hurry. Let us know when you're ready to continue, I'll be happy to keep reviewing new changes (just ping me directly when you update the PR, please :)).

@gibson042
Copy link
Member

I think this means that jQuery._evalUrl can also be simplified.

@mgol
Copy link
Member

mgol commented May 13, 2019

I think this means that jQuery._evalUrl can also be simplified.

@gibson042 I was thinking about that but it now also supports the options object that's used to pass nonce in domManip...

But, I guess, we could move the logic back to the converter now since it won't be executed for bad requests. Is that what you had in mind?

Copy link
Member

@mgol mgol left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One more comment (but see the previous ones as well).

@gibson042
Copy link
Member

But, I guess, we could move the logic back to the converter now since it won't be executed for bad requests. Is that what you had in mind?

Yeah, it should no longer need the dataFilter kludge AFAICT.

@skrobinson
Copy link
Contributor Author

@mgol I have pushed updates to my PR branch.

You made a good call asking for more tests. I found my first if was not sufficient.

P.S. I'll look at jQuery._evalUrl after this PR lands.

Copy link
Member

@mgol mgol left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the delay. I like the way you generated many test cases, it's easy to see what's going on. I left a few comments.

@mgol

This comment has been minimized.

@skrobinson

This comment has been minimized.

@mgol

This comment has been minimized.

@skrobinson
Copy link
Contributor Author

@mgol This PR is ready for another review.

RE: the many test cases. I copied the pattern used for the "jQuery.ajax() - cache" tests, once I understood how those tests worked.

Copy link
Member

@mgol mgol left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few more minor comments but it looks almost done to me, thanks!

@mgol
Copy link
Member

mgol commented Sep 5, 2019

@skrobinson before applying further updates, could you rebase this PR over current master? The current base is from April this year & a lot has changed in the setup since then.

Unsuccessful responses may not contain text convertible to the intended
type (e.g. json, script, etc.) using the normal converter.  The two added
test cases only check for `dataType: "script"`.

Fixes jquerygh-4250

Signed-off-by: Sean Robinson <[email protected]>
Signed-off-by: Sean Robinson <[email protected]>
The exact error message is platform dependent, so just check that a message
is present.  Firefox says "File not found" while Chrome says "Not Found".

Signed-off-by: Sean Robinson <[email protected]>
The original change was meant to prompt Travis tests before submitting a
Pull Request.  With a PR in, this is no longer necessary.

This reverts commit 1146399.

Signed-off-by: Sean Robinson <[email protected]>
s.dataType is optional and may be undefined.  Look for "script" in the
chain of convertible types.

Expands tests by building on mgol's previous work mocking failed services.

Signed-off-by: Sean Robinson <[email protected]>
The original flow was an attempt to keep a pristine copy of the default
options.  But, it doesn't account for how JavaScript works.  The object
literal is created anew on each call to request and does not need to be
protected.

Signed-off-by: Sean Robinson <[email protected]>
The jQuery project's standard missing file is 404.txt.

Signed-off-by: Sean Robinson <[email protected]>
Use a common object which fails any test attempting to convert the
response as a script.

Signed-off-by: Sean Robinson <[email protected]>
Signed-off-by: Sean Robinson <[email protected]>
@skrobinson
Copy link
Contributor Author

@mgol These latest changes are complete and I've rebased onto today's master.

Copy link
Member

@mgol mgol left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, thanks!

Copy link
Member

@timmywil timmywil left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@mgol mgol closed this in 50871a5 Sep 26, 2019
@mgol
Copy link
Member

mgol commented Sep 26, 2019

Landed, thanks @skrobinson for keeping up with our review comments!

@lock lock bot locked as resolved and limited conversation to collaborators Mar 27, 2020
mgol pushed a commit that referenced this pull request Apr 6, 2020
The script transport used to evaluate fetched script sources which is
undesirable for unsuccessful HTTP responses. This is different to other data
types where such a convention was fine (e.g. in case of JSON).

(cherry picked from 50871a5)

Fixes gh-4250
Fixes gh-4655
Closes gh-4379
@mgol mgol modified the milestones: 4.0.0, 3.5.0 Apr 6, 2020
@mgol
Copy link
Member

mgol commented Apr 6, 2020

Backported to 3.x-stable in da3dd85.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Development

Successfully merging this pull request may close these issues.

5 participants