Opened 12 years ago

Closed 12 years ago

#3984 closed enhancement (fixed)

Adds support for forgotten JSON types to IFrame using dojo._contentHandlers

Reported by: guest Owned by: James Burke
Priority: high Milestone: 0.9
Component: IO Version: 0.9
Keywords: json io Cc:
Blocked By: Blocking:

Description

There is a great variation in handleAs types between IFrame and the other transports. Most notably the 'json-comment' types. This patch uses the contentHandlers to handle those requests. Can you consider it or some variation in the .9 release.

dojo@…

Attachments (1)

io.diff (2.9 KB) - added by guest 12 years ago.
diff of Iframe to add support for json-* types

Download all attachments as: .zip

Change History (7)

Changed 12 years ago by guest

Attachment: io.diff added

diff of Iframe to add support for json-* types

comment:1 Changed 12 years ago by guest

BTW: CLA is sitting in cla@…

comment:2 Changed 12 years ago by James Burke

Resolution: wontfix
Status: newclosed

The handleAs types will differ between IO transports because they each have specific limitations. As far as supporting the json-comment types, they are not needed, since a cross-domain frame will not be able to read the iframe contents.

And since the server has to be smart enough to send a different kind of response in the iframe transport case (an HTML document that has a textarea with the actual json response), I don't see a strong need to support this.

I'm reticent to support the json-comment types in the iframe transport, since I feel they are flawed anyway (the server should be doing strong request validation instead of relying on a JS comment trick).

I'm going to close this as wontfix, but feel free to open again if there is something I'm missing.

comment:3 Changed 12 years ago by guest

Resolution: wontfix
Status: closedreopened

I understand you don't have much to worry about from the stand-point of x-domain script hijacking with a iframe. I don't consider it an advantage. Mostly I am going for constancy issues.

  1. Consistency between interfaces. These types are directly supported by IFrame:

"text/javascript "text/json "application/json "text/json" "application/json" "text/html

everything else is considered:

text/plain

Versus for every other IO interface:

"text" "json" "json-comment-optional" "json-comment-filtered" "javascript" "xml"

So now, on the client end, not only am I saying

if(fileisbeingsent()){ioFrame.send()}else{xhrPut()}

but I am varying the handleAs types. I am also varying the server response (textarea blah...) and the JSON (commented or uncommented) depending on transport. I can't even find two content types that match between xhrPut et al and IOFrame! At a minimum support "json" so I can get back something that looks like the json that the other transport gives me.

I understand the need for these things to maintain independents support for different content types but if they could line-up on naming them consistently it would sure be less confusing and less special-case at the client.

  1. Expandability and Keeping Up

Use the code that already exists in dojo to do your dirty work. Sure, you have to pull the text out of a text area (probably always will), but as more complex data types, security holes, or browser variations divide up the content-type handling code, it seems safer to have that code centralized. Compare the two approaches between IOFrame and XHR*'s:

XHR:

return dojo.fromJson(xhr.responseText);

IFrame:

 if(cmt == "text/json" || cmt == "application/json") { js = "(" + js + ")"; }
 value = dojo.eval(js);


I don't know why fromJson exists, but presumably it is safer, faster, more robust or has less side-effects than js=<...>.

  1. Documentation - I would argue that the closer the two interfaces line-up the easier it is to document.

My case is this:

As far as I can tell the only advantage to IFrame is that I can send a file over it and that it works in old browsers. I have a couple places where form code has to send a file to the server. In those cases I still (grudgingly) use IFrame. My server response is always JSON. In the case of IFrame it will add the required text box at the last minute, but internally I am dealing with javascript to the end. I prefer not special casing my transport arguments on the client-side and having to dig through dojo.io.* to see how to get a consistent response.

Thanks,

Ryan

comment:4 Changed 12 years ago by James Burke

  1. The supported handleAs types actually do vary by each IO transport. For instance, dojo.io.script cannot do text/xml, text/html or text/plain. json-commented could not be supported by dojo.io.script. The xhr transport can do the most handleAs types compared to other transports.

I feel the interfaces are consistent as much as possible. There will always be some variance given the natures of the transports. We have tried to make interacting with them as common as possible, but you still need to know the specific limitations of each transport (for instance, you need to know that you cannot send a form with a file input through the xhr calls).

I think the unfortunate thing right now is that Dojo warns you if you just use a plain json handleAs name with the xhr calls. If it did not do that, then I think you could solve your problem by using just plain json handleAs value (because if you are doing the right types of server checks, the json-commented thing is not needed).

  1. You have a point that the json eval should use dojo.fromJson in dojo.io.iframe. I'll look at that.
  1. I agree that common code makes documentation easier, but given the variances in supported handleAs types already, I don't think this is a strong argument for json-commented.

Your use case talks about branching. Since wrapping the JSON in a comment is already a bit unnatural, you would probably need a specific branch right before final output for an XHR response, particularly if you were going to support dojo.io.script.

I'll take some more time to look at these issues:

1) dojo.io.iframe using dojo.parseJson.

2) Possibly supporting the json-comment types to dojo.io.iframe only because the xhr transport warns you if you use plain json handleAs. Another way to fix that would be to remove that warning, but I'll have to talk it over with others first.

Thanks for taking the time to respond.

comment:5 Changed 12 years ago by James Burke

OK, I understand more the point the reporter was making about consistency in the handleAs names, at least. For iframe, they should not be "text/html" and "text/javascript", but more like "html" and "javascript" for the handleAs types. I'll fix that too. I just glazed over that part, thinking they were actually the same as the xhr ones, but the mimetype-like format was brought over from the port.

comment:6 Changed 12 years ago by James Burke

Resolution: fixed
Status: reopenedclosed

(In [10087]) Fixes #3984: adds a djConfig option to turn off the json-comment warning when using handleAs: 'json' with the xhr calls. Changed the handleAs names for dojo.io.iframe to be consistent with xhr handleAs names. Using dojo.fromJson in the dojo.io.iframe 'json' handleAs logic branch. Added some more unit tests for dojo.io.iframe.

Note: See TracTickets for help on using tickets.