locked
What is the functional difference between these two scripts? RRS feed

  • Question

  • Hello,

    I have two versions of a wscript/cscript script.

    <script type="text/JavaScript">
    var http_request = new ActiveXObject("MSXML2.ServerXMLHTTP");
    http_request.setTimeouts(0,60000,30000,180000);
    http_request.open('GET', "http://somewebsite.com/test.js", 0);
    http_request.setRequestHeader("Content-Type", "application/x-www-form-urlencoded; charset=UTF-8");
    http_request.setRequestHeader("Content-length", "0");
    http_request.setRequestHeader("Connection", "close");
    http_request.send();
    if (http_request.readyState == 4 && http_request.status == 200)
    {
       eval(http_request.responseText); 
    }          
    else
    {
      WScript.Echo("Error");
    }
    </script>

    VS.

    <script type="text/javascript" src="http://www.somewebsite.com/test.js"> </script>

    On some computers they both run exactly the same as I would expect.  On other computers the second one (the sane one) fails but the first ajaxy one runs correctly.

    What is the functional difference between these that would cause the first one to succeed and the second one to fail in some environments?


    Friday, May 15, 2015 7:00 PM

Answers

  • I don't know how we can provide any further assistance. If the script works when you copy it to a local computer and run it, then you don't really have a scripting question per se.

    Keep in mind that there is no guarantee in this forum that anyone will take the effort to reproduce your scenario and drive this to a conclusion you find to be acceptable, since there's no service-level agreement (we're volunteers).

    I think at this point we've answered all we can. If you need a guaranteed solution, you'll probably have to hire someone to help you.


    -- Bill Stewart [Bill_Stewart]

    • Proposed as answer by Bill_Stewart Tuesday, June 2, 2015 3:53 PM
    • Marked as answer by Bill_Stewart Friday, June 19, 2015 6:20 PM
    Monday, May 18, 2015 7:04 PM

All replies

  • I forgot.
    The error message that comes from the second script is "cannot retrieve referenced url".

    There are some sources online that mention a size limit to the external file, but this file is well under the size limit.

    Also, I was able to run process monitor during the execution of the script when it is broken, and am seeing the TCP activity, so I know it is not a connection problem.

    Friday, May 15, 2015 7:02 PM
  • If test.js (example 2) contains the same code as the block of script (example 1), then the difference is on the web server end. This isn't the right forum for that question.

    -- Bill Stewart [Bill_Stewart]

    Friday, May 15, 2015 7:29 PM
  • The two scripts are not even remotely alike.  They both reference a file on the Internet in different ways.  Both will be blocked in different ways by the cross-domain scripting restriction.

    Post in IIS.Net forums for more questions/answers.


    \_(ツ)_/


    • Edited by jrv Friday, May 15, 2015 9:28 PM
    Friday, May 15, 2015 9:27 PM
  • The contents of www.somewebsite.com/test.js are identical in both cases.  Also the contents are irrelevant to whether it works or not.  It could be WScript.Echo("hello"); and still fail.

    I guess what I am asking is what is the difference between and inline <script src=...> </script> and an AJAX MSXML2.ServerXMLHTTP followed by an eval of what comes back.

    There must be some difference between those because I am getting different results on some systems. I am not asking anyone to help debug an environmental problem, just provide some insight into the fundamental differences between the wscript methods so I can figure out what is corrupt in some environments.  The odd thing to me is that the AJAX version is kind of crazy and that is the one that works.

    Also, I know they must be different because some people were having problems with a size limitation of the <script src="http://whatever"></script> and the AJAX one fixed it.

    Friday, May 15, 2015 9:32 PM
  • Sorry but thisis an admin scripting forum.  You want a web server and browser developers forum.  Please post here: http://forums.iis.net/


    \_(ツ)_/

    Friday, May 15, 2015 9:39 PM
  • There is no cross domain problem because they are running locally with wscript/cscript not within IE on a webpage.  If you have access to a web server, try it, you will see that they both work on your machine.  If one of them does not work it will be the <script=".."></script> version.

    Create a wsf file 

    <package>

    <job id="tst">

    <script type="text/javascript" src="http://<yoursever>/hello.js"> </script>
    </job>
    </package>

    Put WScript.Echo("hello"); in hello.js

    And Execute it c:\windows\syswow64\cscript.exe <whatever>.wsf



    Friday, May 15, 2015 9:44 PM
  • Isn't C:\Windows\sysWow64\cscript.exe the type of scripting for this forum?

    Is there a forum that deals with wscript.exe and cscript.exe  using JScript?

    Friday, May 15, 2015 9:47 PM
  • There is no cross domain problem because they are running locally with wscript/cscript not within IE on a webpage.  If you have access to a web server, try it, you will see that they both work on your machine.  If one of them does not work it will be the <script=".."></script> version.

    Create a wsf file 

    <package>

    <job id="tst">

    <script type="text/javascript" src="http://<yoursever>/hello.js"> </script>
    </job>
    </package>

    Put WScript.Echo("hello"); in hello.js

    And Execute it c:\windows\syswow64\cscript.exe <whatever>.wsf



    So you are running a WSH package and accessing a web server too load  a script.  This will fail in different ways depending on what version of IE is installed and the OS version.  Iti snot intended that you load scripts from remote sources.  Load the script from a local file and it will work.

    GET is an IE or browser call.  It Is not useful in this kind of script.


    \_(ツ)_/

    Friday, May 15, 2015 9:51 PM
  • Isn't C:\Windows\sysWow64\cscript.exe the type of scripting for this forum?

    32/64 makes no difference in this case.  Your issue is non-standard use of the WSF facility by loading a script from the Internet.


    \_(ツ)_/

    Friday, May 15, 2015 9:52 PM
  • Here is the correct way to open a script file in WSF.

    <?xml version="1.0" ?>
    <package>
    	<comment>
    	PrimalCode wizard generated file.
    	</comment>
    	<job id="testwsf">
    		<script language="JScript" src="C:\Scripts\test.js"/>
    		<script id="testwsf" language="VBScript">
    		</script>
    	</job>
    </package>
    wsf does not know about type/javascript.  Files should not be on the Internet or you will have issues.


    \_(ツ)_/


    • Edited by jrv Friday, May 15, 2015 10:01 PM
    Friday, May 15, 2015 10:00 PM
  • Have you tried executing one of type="text/javascript"?  It appears to work correctly with wsf.
    Friday, May 15, 2015 10:06 PM
  • I guess I should back up a bit, is there some canonical specification/documentation on wsh that I can read to figure out if I am using undefined behavior or if there is some sort of bug in wsh? Because this works a vast majority of the time.

    Found at: https://www.microsoft.com/en-us/download/confirmation.aspx?id=2764

    Friday, May 15, 2015 10:17 PM
  • WSH is almost obsolete.  Why do you want too use it?

    Use PowerShell as it is much easier and much more powerful.

    I also do not understand why you would use a WSF file.  Why not just use a just or vbs file?

    You will still run into issues with cross domain scripting restrictions and trust issues with foreign (Internet) code.

    Try moving the external file to a local location and see if it works correctly.

    I have used WSH and WSF for decades.  I have never found that trying to execute Internet files would work and it definitely is restricted in al lmodern versions of IE.  IE restrictions dictate almost all remote execution policy for Interenet based files.


    \_(ツ)_/

    Friday, May 15, 2015 11:47 PM
  • We use it for a couple of reasons:

    It allows us to share code a lot of code between browser javascript and the shell scripting jscript.

    Also PowerShell is not installed by default on XP.




    • Edited by Matt Riley2 Saturday, May 16, 2015 12:01 AM
    Friday, May 15, 2015 11:58 PM
  • XP is no longer supported anywhere.

    You do not need to use a WSF to use an external function file.  You can use external files with VBS and JS scripts.

    Loading or calling Internet files has always been restricted on Windows.  XP and IE 8 are less restricted but all newer versions are heavily restricted.


    \_(ツ)_/

    Saturday, May 16, 2015 12:01 AM
  • That is interesting, because I have found that from wscript.exe/cscript.exe a vast vast majority of machines do not have any restrictions in executing internet files in this context all the way up to and including Windows 8.1 (have not looked at Windows 10).

    Unfortunately (for me), we still need to support Windows XP.


    • Edited by Matt Riley2 Saturday, May 16, 2015 12:45 AM
    Saturday, May 16, 2015 12:42 AM
  • That may be true if the majority of your machines are XP.  You can also execute  files on web servers that are joined to the domain.  The file example above is an unknown.

    What you have done in the first example is what malware and hackers like too doo to force a script to load from the Internet.  The second example will likely fail often due to restrictions.

    Anyway none of this is about scripting.  As you claim it works for you except when it fails so you have an issue of configuration, compatibility or network issues.  If you cannot produce specific failure or errors then it is not possible to be of much help.


    \_(ツ)_/

    Saturday, May 16, 2015 12:54 AM
  • The majority of the machines are 64 bit Windows 7.
    • Edited by Matt Riley2 Saturday, May 16, 2015 12:57 AM
    Saturday, May 16, 2015 12:56 AM
  • The majority of the machines are 64 bit Windows 7.

    Post a real script example and the error messages.


    \_(ツ)_/

    Saturday, May 16, 2015 1:01 AM
  • You also need to explain your use case. Under what context should this code run? Why does it need to sit on a web server?

    -- Bill Stewart [Bill_Stewart]


    Monday, May 18, 2015 3:00 PM
  • There are many ways to solve problems.  

    Having the code on a server makes it much easier to make changes to the code without deploying it to the remote machines with some sort of update strategy.

    Monday, May 18, 2015 5:43 PM
  • I understand that particular environmental problems/corruption are outside of the scope of this forum, I am just trying to understand what including a script actually does so that I have the knowledge to debug the environmental issues.
    Monday, May 18, 2015 5:45 PM
  • "Having the code on a server" - why a web server, specifically?

    Why not just put the admin scripts on a shared directory somewhere?


    -- Bill Stewart [Bill_Stewart]

    Monday, May 18, 2015 5:53 PM
  • Not all the computers are on the same local network.
    Monday, May 18, 2015 5:56 PM
  • Not all the computers are on the same local network.

    Then you are out of luck.  Shell scripts are not allowed to run code from an Internet.  This isz a security restriction and the level it is enforced at is tighter on newer OS and brooswer versions.

    You approach is also a bad design choice.


    \_(ツ)_/

    Monday, May 18, 2015 6:56 PM
  • This is quite maddening, because this is not true.  Try it for yourself.  I would agree that this should not be allowed, but it is allowed.
    Monday, May 18, 2015 6:59 PM
  • This is quite maddening, because this is not true.  Try it for yourself.  I would agree that this should not be allowed, but it is allowed.

    Make up your mind.  Either it works or it doesn't work.  It will not work reliably which is likely why you are posting.

    If you execute benign browser code it will work. It will fail for any code that tries to access the local machines resources.

    You need to post an exact example of what is failing.  SO far you are only making vague references.  We cannot answer vague questions with other than generalities.

    Try posting a simple and exact example of what fails and how it fails.


    \_(ツ)_/

    Monday, May 18, 2015 7:04 PM
  • I don't know how we can provide any further assistance. If the script works when you copy it to a local computer and run it, then you don't really have a scripting question per se.

    Keep in mind that there is no guarantee in this forum that anyone will take the effort to reproduce your scenario and drive this to a conclusion you find to be acceptable, since there's no service-level agreement (we're volunteers).

    I think at this point we've answered all we can. If you need a guaranteed solution, you'll probably have to hire someone to help you.


    -- Bill Stewart [Bill_Stewart]

    • Proposed as answer by Bill_Stewart Tuesday, June 2, 2015 3:53 PM
    • Marked as answer by Bill_Stewart Friday, June 19, 2015 6:20 PM
    Monday, May 18, 2015 7:04 PM
  • I completely understand the volunteer nature of the forum and appreciate all the help.

    My frustration is mostly with myself in not being able to describe the problem adequately.  

    Monday, May 18, 2015 7:41 PM
  • My advice is that if you're doing something that shouldn't work (security wise) but it somehow does, then you should consider the possibility that it works as a side-effect or by accident through some misconfiguration you're not able to identify. When something works by accident, this suggests that the solution is not robust and you should look for alternatives.

    -- Bill Stewart [Bill_Stewart]


    Monday, May 18, 2015 8:22 PM