Opened 12 years ago

Closed 11 years ago

#2856 closed defect (invalid)

doesn't handle well text/plain response from multipart request

Reported by: guest Owned by: anonymous
Priority: high Milestone: 1.2
Component: Dojox Version: 0.4.2
Keywords: multipart response IframeTransport error Cc: vic@…
Blocked By: Blocking:

Description (last modified by Tom Trenka)

I send an upload multipart request that way : var bindArgs = {

url: "SRB/SRBUpload", formNode: formNode, mimetype: "text/plain", load: function(type,data,evt) {


}, error: function(type,error) {




everything goes well, my file is uploaded, but it always triggers the "error:" function with that message : IframeTransport? Error: TypeError?: ifd.getElementsByTagName("textarea")[0] has no properties

unless the returned message should be : "the file has been uploaded to /dir/dir/dir/file"

Change History (11)

comment:1 Changed 12 years ago by alex

Resolution: invalid
Status: newclosed

this is a design limitation of file uploading. It's well documented. Invalid.

comment:2 Changed 12 years ago by (none)

Milestone: 0.4.3

Milestone 0.4.3 deleted

comment:3 Changed 11 years ago by guest

Resolution: invalid
Status: closedreopened

With all due respect, how exactly is this a design limitation of file uploading? I can't find the documentation you speak about, nor can I find how this bug is at all invalid. I'm having this exact same problem when using pasted code from the file upload examples from the dojo book. I've already spent at least 16 hours debugging this problem, and as far as I can tell my data value is being read before the data is available.

Vic Fryzel <vic@…>

comment:4 Changed 11 years ago by dante

Cc: vic@… added
Resolution: invalid
Status: reopenedclosed

the secret is (documented in dojo/io/iframe.js):

"the response must be returned in a textarea tag", because that is the only secure, reliable way to handle IO on an iframe.

the error is saying it's not finding the textarea isn't expecting. multipart forms are grotty, and the iframeIO is a workable solution, though has these "documented" limitation.

the file upload example in the book is based on dojox.widget.FileInput?, which the 'default' backend handler in the dojox/widget/FileInput/ folder has a textarea, and a commenting explaining it's usage.

load will not fire unless it finds the textarea, and data will be populated by the contents of the textarea found, and passed to load:

hope this helps. reclosing.

comment:5 Changed 11 years ago by guest

Yes, but I'm sending back my data in a textarea tag, that's where I'm having the problem. The output of my backend is <textarea>[data]</textarea> and I'm still getting this error.

comment:6 in reply to:  5 Changed 11 years ago by guest

Replying to guest:

Yes, but I'm sending back my data in a textarea tag, that's where I'm having the problem. The output of my backend is <textarea>[data]</textarea> and I'm still getting this error.

Again, Vic Fryzel <vic@…>

comment:7 Changed 11 years ago by guest

To be clear, I've confirmed in Firebug that the response my application is sending to the iframe is indeed <textarea>[some json text here]</textarea>. Firebug shows it as the response to the HTTP request. But the data never makes it to the iframe data handler, because I get the error:

Error: TypeError?: ifd.getElementsByTagName("textarea")[0] has no properties

comment:8 Changed 11 years ago by dante

okay, then that's a different story. the [0] after elementsByTagName means the first textarea. is that the case? does it work if you wrap your response in the textarea (don't suspect this will work, it's not finding the ifd) in a json object and handleAs:"json"

also, this bug refers to the 0.4 version. is that what you are using as well? if that's not the case (eg you are using 1.0), mimetype has been deprecated, and handleAs:"text" is the only html/plaintxt handler available.

if you _are_ using 1.x, have handleAs:"text" and [textarea]some text to returntextarea as the first textarea element in the response page, please reopen this ticket and attach a simple test case (mostly just to see how you are setting up the formNode form. (which is also just form: now with the 1.x

either way, if this discussion continues on much more we should continue it as a support incident on the forums if it's not too much trouble for you.

comment:9 Changed 11 years ago by guest

Resolution: invalid
Status: closedreopened

Yeah, it's the first and only textarea tag. I'm using dojo 1.0.2. I'm also aware of the switch from text/json to json, and have been using json throughout all of my tests. I've tried everything I can think of, and have used many different examples. I've been up and down the dojo code itself a few times, too. Despite all of the if statements in my code, I'm assuming that because I'm getting the TypeError? that my code is actually executing the upload.

My code is as follows:

_upload: function(/* Event */e) {
	if(this.uploadFile.value) {
		var form = document.createElement('form');
		var file = dojo.clone(this.uploadFile);
		var title = dojo.clone(this.uploadTitle);
		var description = dojo.clone(this.uploadDescription);
		method: "POST",
		timeout: 10000,
	  	url: this.uploadUrl,
		form: form,
	  	handleAs: "json",
		handle: function(data) { console.debug(data); }


Here is the response I see from my application in Firebug:

<textarea>{identifier: "attachments", items: []}</textarea>

And here is the error that I receive after an upload:

TypeError: ifd.getElementsByTagName("textarea")[0] has no properties

Thanks for the help. Vic Fryzel <vic@…>

comment:10 Changed 11 years ago by dylan

Component: GeneralDojox
Milestone: 1.2

comment:11 Changed 11 years ago by Tom Trenka

Description: modified (diff)
Resolution: invalid
Status: reopenedclosed

Without a test case, and given the age of this ticket, I'm going to mark it as "invalid". The discussion here seems less like an actual bug and more like there's something individual going on.

Vic, if you don't mind and this is still an issue, please move this discussion over to the Dojo Core Support forums.

regards, trt

Note: See TracTickets for help on using tickets.