-
Notifications
You must be signed in to change notification settings - Fork 20.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ajax: Support binary data (including FormData) #5197
Conversation
3584c0b
to
909c466
Compare
// Apply prefilters | ||
inspectPrefiltersOrTransports( prefilters, s, options, jqXHR ); | ||
|
||
// Convert data if not already a string | ||
if ( s.data && s.processData && typeof s.data !== "string" ) { | ||
s.data = jQuery.param( s.data, s.traditional ); | ||
} | ||
|
||
// Apply prefilters | ||
inspectPrefiltersOrTransports( prefilters, s, options, jqXHR ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think moving prefilters ahead of string coercion is a breaking change with respect to custom prefilters, cf. https://api.jquery.com/jQuery.ajaxPrefilter/ (emphasis mine):
originalOptions
are the options as provided to the$.ajax()
method, unmodified and, thus, without defaults fromajaxSettings
Is there a way to instead establish something like prefilter phases?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The line that now happens after the prefilters is only setting data
, not options. Is there any change that I'm missing?
BTW, I would also consider this a breaking change regardless of the above, that's why I'm targeting it at v4.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good for 4.0. Might need a note in docs about the prefilter going before stringifying s.data
, if that was ever documented.
// `Content-Type` for requests with `FormData` bodies needs to be set | ||
// by the browser as it needs to append the `boundary` it generated. | ||
if ( s.data instanceof window.FormData ) { | ||
s.contentType = false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note to self: check if this could be overridden in options if this is set to false
for all binary data, not just FormData
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, this cannot be changed via settings as of now. 😕 I'll need another patch, I think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PR: #5205
Two changes have been applied: * prefilters are now applied before data is converted to a string; this allows prefilters to disable such a conversion * a prefilter for binary data is added; it disables data conversion for non-string non-plain-object `data`; for `FormData` bodies, it removes manually-set `Content-Type` header - this is required as browsers need to append their own boundary to the header Ref jquerygh-4150
909c466
to
5e8fc4d
Compare
PR jquerygh-5197 started treating all non-string non-plain-object `data` values as binary. However, `jQuery.ajax` also supports arrays as values of `data`. This change makes regular arrays no longer be considered binary data. Surprisingly, we had no tests for array `data` values; otherwise, we'd detect the issue earlier. This change also adds a few such missing tests. Ref jquerygh-5197
I missed handling array |
The way jquerygh-5197 implemented binary data handling, `processData` was being explicitly set to `false`. This is expected but it made it impossible to override it to `true`. The new logic will only set `processData` to `false` if it wasn't explicitly passed in original options. Ref jquerygh-5197
The way gh-5197 implemented binary data handling, `processData` was being explicitly set to `false`. This is expected but it made it impossible to override it to `true`. The new logic will only set `processData` to `false` if it wasn't explicitly passed in original options. Closes gh-5205 Ref gh-5197
PR jquerygh-5197 started treating all non-string non-plain-object `data` values as binary. However, `jQuery.ajax` also supports arrays as values of `data`. This change makes regular arrays no longer be considered binary data. Surprisingly, we had no tests for array `data` values; otherwise, we'd detect the issue earlier. This change also adds a few such missing tests. Ref jquerygh-5197
PR gh-5197 started treating all non-string non-plain-object `data` values as binary. However, `jQuery.ajax` also supports arrays as values of `data`. This change makes regular arrays no longer be considered binary data. Surprisingly, we had no tests for array `data` values; otherwise, we'd detect the issue earlier. This change also adds a few such missing tests. Closes gh-5203 Ref gh-5197
PR gh-5197 started treating all non-string non-plain-object `data` values as binary. However, `jQuery.ajax` also supports arrays as values of `data`. This change didn't land on `3.x-stable`; however... Surprisingly, we had no tests for array `data` values. This change backports a few such missing tests added in gh-5203. Ref gh-5197 Ref gh-5203
Summary
NOTE: Please don't review the first commit; that one is #5196, it was just easier for me to depend on it.(that PR landed)Two changes have been applied:
this allows prefilters to disable such a conversion
for non-string non-plain-object
data
; forFormData
bodies, itremoves manually-set
Content-Type
header - this is requiredas browsers need to append their own boundary to the header
Ref gh-4150
+39 bytes
. We should discuss whether we want this fully in core or just the small change of running prefilters early enough for this to be possible. It is quite generic, though, with the small exception of specialFormData
treatment - which, I think, is not necessarily desired in all cases? Unless it is - then the PR overhead would be+20
bytes instead of+39
.Checklist