Opened 14 years ago

Closed 14 years ago

Last modified 13 years ago

#806 closed defect (worksforme)

file:// url's fail on ie 5.5 (xmlhttprequest incompatibility)

Reported by: dojojojo Owned by: alex
Priority: high Milestone:
Component: Core Version: 0.3
Keywords: Cc: [email protected]
Blocked By: Blocking:


Dojo modules fail to load reporting the error "failed loading src/widget/button.js due to error [Error: the parameter is incorrect. ]"

I have traced this down to the dojo.hostenv.getText() function. It is throwing an exception on the following call:

http var is instance of xmlhttprequest obj"get", uri, async_cb ? true : false)

It is failing because the uri is pointing to a local (relative) path. It does this for any variation of a local path. For example:

file:///c:/src/widger/button.js c:/src/widger/button.js src/widger/button.js

The function does not throw an exception if a path using http:// (i.e. web url) is passed in as the second arg. It appears to me that earlier versions of MSXML don't support local file resolutions through xmlhttprequest.

Change History (12)

comment:1 Changed 14 years ago by alex

Milestone: 0.3.1
Owner: changed from anonymous to alex
Status: newassigned

comment:2 Changed 14 years ago by dojojojo

There is windows specific code that can be used to read the local file. I tried executing the following code on an exception from

try {'get', uri, false); } catch(e) { var fullPath = "c:/test/" + uri; object requires full path, not sure if this is available as a hostenv var or something var fso = new ActiveXObject("Scripting.FileSystemObject?") var file = fso.OpenTextFile?(fullPath, 1); return file.ReadAll?(); }

comment:3 Changed 14 years ago by bill

Summary: dojo does not work with ie 5.5 due to xmlhttprequest incompatibilityfile:// url's fail on ie 5.5 (xmlhttprequest incompatibility)

Changing the title to reflect that this is an issue with file:// urls only (http:// urls work fine)

comment:4 Changed 14 years ago by Tom Trenka

Whoa. The code that you've posted there dojojojo is a major, major security hole and can only be executed on a trusted domain; in fact, unless you have the windows script host installed it will probably fail (Dictionary and FSO are part of WSH, iirc).

Putting that code into Dojo would be bad, bad, bad :(

In other things, I'm not sure this is a bug we can solve. If MSXML won't read something using the file:// protocol, the only other suggestion I'd have is maybe have the XDomain stuff take a look at this issue.

comment:5 Changed 14 years ago by alex

Tom: I don't think what he's asking for is unreasonable and I don't see how it breaks the security model. If Dojo is loaded from the filesystem, we should have perms to go get other data from the FS. Win-win.

Or am I missing something?

comment:6 Changed 14 years ago by Tom Trenka

We can't be sure a windows box has the Scripting.FileSystemObject? installed, and we also can't be sure the security settings in IE won't prevent the object from being created. This is related to that whole "I used to be able to open your CD drive from a site" security deal...we can try it but I do remember (from an old job) that doing this kind of thing can open holes, and given the way MS has been trying to patch things...

We can try it but I'd recommend pursuing another path :(

comment:7 Changed 14 years ago by dojojojo

Thank you for your thoughtful consideration on this matter. I've looked into the issue a bit more. Below is a listing of some additional information I've gathered.

  • I haven't found a system that doesn't have the windows scripting host installed. I've tested this on Win98, Win2k, WinXP. Even if it weren't installed you would be failing from a failure, which is still the same as it would be if you just let it fail in the first place.
  • Microsoft does not recommend using this family of objects on the client from an internet page. It is intended for server side pages. I take that to mean intranet/maintenance type pages.
  • The object is not marked as "safe for scripting". The means you get the "are you sure you want to run this potentially unsafe object" dialog.
  • If you answer yes to this dialog the object still works in all versions of IE (5.5 to 7.0 beta2).
  • The FileSystemObject? has *write* access as well, which does make it very unsafe if there is an exploit path to that code.
  • Dojo also fails to work locally with IE7 (beta2). It throws a different error from the same call (an 'Access Violation' rather than an 'Invalid Parameter' as seen in IE 5.5). It appears that MS' intent is to have XMLHTTP only work through HTTP. I guess IE 6 was a fluke...


This is a difficult problem. Using the MS scripting FileSystemObject? seems like an intractable option due to security issues and the fact that you will get an ActiveX warning dialog (which pretty much destroys the user experience you are trying to create). Currently for my situation I am planning on implementing a facade XMLHTTP interface which I will use to properly handle local file resolutions. I will keep an eye out for any other javascript accessable local filesystem functionality. If I find anything before you guys do I'll make sure to post it.

Thanks again, Christian

comment:8 Changed 14 years ago by Tom Trenka


You're right, my apologies; I just double-checked with a friend of mine that's been doing MS consulting for 10+ years, and he confirmed that WSH 5.1 was shipped with Win98 and 2000/Me, and WSH 5.6 was shipped with XP/2003. But I do remember the security dialog, and that's more of what I was referring to (as well as having the thought of trying to control the user's file system from a browser)...

FSO was definitely intended to be used in trusted WSH scripts, network maintenance, and server-side scripting (I use it all the time when developing classic JScript ASP)...using it here in place of XHR is a long way to go for that functionality.

For the application you're developing, is there any way you'd try to use it as an HTML application (i.e. HTA) as opposed to a straight up web page? Writing it as an HTA eliminates a number of the security restrictions IIRC...

comment:9 Changed 14 years ago by dojojojo

I have done some research into HTAs, but they are too restrictive/inflexible for my needs, though HTAs do have interesting security features (zoned security through iframes being one). Right now my applications host the browser control, which they will probably do for a while.

comment:10 Changed 14 years ago by alex

Resolution: worksforme
Status: assignedclosed

So I'm gonna close this bug without implementing the FileSystemObject? branch because I just ran a test on a fully patched Win2K/IE 5.5 box and the system worked without modification. I verified that the installed WSH version is 5.1.

The fact that it works now might be due to a fix for a related but that was disallowing absolute paths in source prefixes previously, but I'm not sure that explains it entirely. Until I've got a reproduceable test case, though, I don't think it makes sense to spend any more effort on the issue.


comment:11 Changed 14 years ago by [email protected]

Cc: [email protected] added

I was testing on a fresh 2k box with an unpatched 5.5 install. I checked out the dojo-2006-06-05 nightly build and tested it on the same box and still saw the issue. I then started patching the system. First with IE 5.5 SP2 and then with windows updates. The IE patch didn't fix the issue, but either the critical updates or the susbsequent recommended updates did. If you would like specific version numbers I can get those for you.

It should be noted that while this fixed the parser error I was seeing, a lot of the widget demos would not work. I verified they worked on a Win2k machine with IE6.0.

comment:12 Changed 13 years ago by (none)

Milestone: 0.3.1

Milestone 0.3.1 deleted

Note: See TracTickets for help on using tickets.