Opened 10 years ago
Closed 9 years ago
#12750 closed defect (fixed)
[patch][ccla] Forced default content type prevents FormData object in dojo/request
Reported by: | ghiloni | Owned by: | Bryan Forbes |
---|---|---|---|
Priority: | blocker | Milestone: | 1.8 |
Component: | IO | Version: | 1.6.0 |
Keywords: | Cc: | cjolif | |
Blocked By: | Blocking: |
Description
with the advent of the HTML5 Files API, the FormData? object can be used to post files to an endpoint using XMLHTTPRequest, and more specifically, dojo.xhr. The problem lies within the setup of the native XHR. In dojo.xhr(), the content type is always set. The FormData? object will set the content type on the XHR for you, including the appropriate boundary, which it creates when it serializes the object. The ioArgs.query object should be checked if it is a FormData? instance before setting the default content type (while still respecting the explicit contentType argument, if one is passed).
A suggested patch has been attached. This occurs on all fully HTML5-capable browsers (FF4, Chrome 9, Safari 5) that I've tested.
Attachments (3)
Change History (15)
Changed 10 years ago by
comment:1 Changed 10 years ago by
comment:2 Changed 10 years ago by
Summary: | allow null content type on dojo.xhr when ioArgs.query is a FormData object → [patch][ccla]allow null content type on dojo.xhr when ioArgs.query is a FormData object |
---|
comment:4 Changed 9 years ago by
Owner: | changed from James Burke to Bryan Forbes |
---|
Bulk change to reassign IO tickets to Bryan, since he is working on new dojo/request module. Some of these tickets should probably be closed as already fixed, invalid, or wontfix.
comment:5 Changed 9 years ago by
Cc: | cjolif added |
---|
comment:6 follow-up: 7 Changed 9 years ago by
Priority: | blocker → high |
---|---|
Type: | defect → enhancement |
Some issues with the patch: FormData? would likely trigger a ReferenceError? on older browsers. Also, there's no else clause, so all codepaths are not necessarily covered, are they?
comment:7 Changed 9 years ago by
Replying to peller:
Some issues with the patch: FormData? would likely trigger a ReferenceError? on older browsers. Also, there's no else clause, so all codepaths are not necessarily covered, are they?
I think the else clause is the case they want to cover, i.e. if there is no explicit contentType and that there is a FormData in the query then they don't want a default content type to be set because it will be automatically done.
Changed 9 years ago by
Attachment: | 12750-1_7.patch added |
---|
fixing the issue for 1.7 (working on IE + formatting fix)
Changed 9 years ago by
Attachment: | 12750-1_8.patch added |
---|
comment:8 Changed 9 years ago by
Milestone: | tbd → 1.8 |
---|
comment:9 Changed 9 years ago by
Milestone: | 1.8 → 2.0 |
---|
1.8 is frozen. Move all enhancements to next release. If you need an exemption from the freeze for this ticket, contact me immediately.
comment:10 Changed 9 years ago by
Milestone: | 2.0 → 1.8 |
---|---|
Priority: | high → blocker |
Status: | new → assigned |
Summary: | [patch][ccla]allow null content type on dojo.xhr when ioArgs.query is a FormData object → [patch][ccla] Forced default content type prevents FormData object in dojo/request |
Type: | enhancement → defect |
comment:12 Changed 9 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
The provided patch for 1.7 removes the way to remove the "Content-Type" header that has been in Dojo since 1.0 and would break the API. In 1.7, the following should work without the provided patch:
dojo.xhrPost({ url: "/some/url", headers: { "Content-Type": false }, postData: FormData(dojo.byId("someNode")) }).then(function(){ });
The patch for 1.8 is somewhat correct, however there should be a has test for native FormData support and the instanceof check should be passed into util.parseArgs()
as the third parameter. I checked in a fix and unit test for this. Please include unit tests in the future.
See also #12141