[2.x] response empty with file upload Ext.Ajax.request

[harley.333]

dan1son is on the ball. I forced a status of 200 and the problem disappeared for me too!

Don't know why, but this line (from Ext.data.Connection.js) throws an exception ("Access is denied.") with a status of 400:

doc = frame.contentWindow.document || frame.contentDocument || WINDOW.frames[id].document;

Ext works-around the browser bug by swallowing the exception. (Not a very good practice, but I can't think of a better alternative in this case.)

I'm using IE8 at the moment.

[ryedin]

OK, so I finally isolated my issue, which turns out is similar to the OP, but a bit different so I'm explaining it here in case someone else runs into it.

Apparently, at some point in the last X months (not entirely sure), there must have been some browser security updates in FF and IE (only two browsers we care about for our project at the moment). Basically, we have a very dynamic framework and an extremely large RIA implemented in js, where we lazily load a lot of scripts only when they are needed (certain js is loaded on initial page load to bootstrap the app but from there on out everything is on demand, and it's all running as 1 long running single page app). SOOOO, apparently, now (didn't have issues originally), if you dynamically inject script tags into your containing page's HEAD tag, that automatically renders all iframes on the page (regardless of how those iframes were created) "locked down". So, what was happening was our Ext form was submitting, but was unable to access it's hidden iframe's .document property... thus completely unable to get at any of the returned data. If I take out the code that injects these script tags, it works...

UGH!!!

So, our workaround was to re-engineer the part where we were using the ext form, and that widget became its own page which is now loaded into its own top level iframe "old school".

Talk about annoying. This was a legacy piece of the app (or rather, a piece that hasn't had to be touched for a long long time). Other places we need file upload capabilities have already been implemented with SWFUpload, which is the way I'd recommend everyone else to do it to (and there's a nice Ext.ux extension out there as well).

Eventually, when priorities are right, we'll retrofit that portion of the app to use SWFUpload too. For now, anyone else running into this can benefit from knowing you'll just need to figure out another way. (And obviously this only applies to other people writing single page RIAs with dynamic script tag injection going on)

[harley.333]

ryedin,

I'm also developing a large, single page RIA with dynamic script tags. My solution was to force success: true on fileupload responses. That solved the problem for me. My customer is IE-only.

[Uberdude]

This thread is really old, but thought I'd explain anyway as I too had this problem and found this thread by searching.

The response is empty because the document.domain property of the iframe is more specific than that of the parent page, and thus the browser's same-origin-policy prevents access to it. For details, including a workaround, see my post http://www.sencha.com/forum/showthre...domain-changed