Hi,

I am trying to setup O4W. I followed the Quick Start guide 9.2.1 step by step. I could get the O4W webpage to open. However clicking on any of the links returns this error:

CGI ERROR

The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are: (none)

I have done the registry settings as shown and I have started the OEsocketserver.jar.

It could be a security/web server issue. Before we look into the web server setup try running OESocketServer in debug mode.

1) Stop the OEngineServer service.

2) Start a command prompt and change directory to the root directory where oinsight.exe is located.

3) Run the command:

java -jar OESocketServer.jar -d 3

You should see a short welcome message. Try logging into the O4W page, do you see any activity in the command prompt? If not, then OECGI isn't able to connect to the OESocketServer (aka OEngineServer service).

Also, while in debug mode try the url http://localhost/examples/oecgi3.exe/inet_trace . Does it succeed? Please substitute http://localhost/examples/ for the path to your oecgi3.exe program.

When OESocketserver is run from debug mode, I get this message (repeated every 5 sec) when I try running INET_TRACE or any other procedure.

'In OEngineFactory:CleanupTask - running used engine cleanup'

The browser output is the same: 'The specified CGI application misbehaved by not returning a complete set of HTTP headers.'

I checked the eserver.cfg port number setting matches the registry value.

I checked permissions allow scripts and executables in IIS manager(v5.1).

This helps narrow down the problem. The activity you see in the command prompt indicating "engine cleanup" is normal chatter from the OESocketServer process. Since you didn't see any activity when the inet_trace was attempted this indicates the registry isn't configured correctly.

If you are on a x64 edition of windows then check the registry branch HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\RevSoft\OECGI3 and for 32bit versions of windows check HKEY_LOCAL_MACHINE\SOFTWARE\RevSoft\OECGI3. If you can't find the registry branch corresponding to your registry then the default branch should be setup.

My guess is you have a x64 machine and accidentally configured the non-WOW6432Node which prevents OECGI3 from locating the correct settings.

To setup the registry open the root OpenInsight directory and locate OECGI3_WOW6432.REG and OECGI3.REG. These files respectively correspond to the x64 and 32 bit editions of windows. Merge the file corresponding to your machine into the registry.

You should now have registry settings for OECGI3. Verify they are correct for your OpenInsight system and try the test again. This time you should see additional messages in the OESocketServer window.

It's possible a local firewall is preventing the connection from OECGI3 to the ServerPort and Server URL (i.e. hostname) specified in the registry. Please check your firewall allows connections to the port specified.

I have a 32-bit Windows XP, I checked the registry and verified that I have the same settings as shown in the Quick Start Guide.

I had already run OECGI3.reg to get the default settings and then created separate settings (only file different mode=2) for a virtual directory.

I have disabled windows firewall and escan's firewall.

I have installed OI in a custom directory, I guess this should not have any effect.

I am still having problem with running any CGI routine. No sign of any interaction with OEsocketserver.

Hi, Arsath. Let's test to see that we can, indeed, communicate with the engine server.

First, if you've set it up to run as a service, stop the service.

Next, open up a DOS command prompt, "cd" to your OpenInsight folder, and type in the following:

java -jar oesocketserver.jar -d 3

This should start up the engine server in a "debug" mode. You should see a message indicating that it has started up.

Finally, open up another DOS command prompt, and type in the following:

telnet localhost 8088

replacing the "8088", if necessary, with the port that your engine server has been configured to listen on. If you are able to connect, you will be presented with a "connecting" message and then a blank screen.

Type in the following:

abcdefgh

These characters will not echo, but after the last character is typed, the telnet client should close and the engine server should report that it received an empty request("Originally received request: "). You can then terminate the engine server by typing ^C (control+C). Did your engine server react as described? Thanks, - Bryan Shumsky Revelation Software </QUOTE> —- === At 25 JUN 2011 06:42AM Asraph Ali wrote: === <QUOTE>Hi Bryan I ensured the oesocketserver was stopped, when I start the service in debug mode and telnet localhost 8088 followed by abcdefgh (same port as in eserver.cfg), the telnet session closes as you mentioned but I get no sign of activity in the debug info, the only thing that I see is running used engine cleanup </QUOTE> —- === At 25 JUN 2011 11:06AM bshumsky wrote: === <QUOTE>Hi, Arsath. Thanks for checking that. The fact that you don't see any response in the engine server during this test is probably ok; I may have a slightly different version, which outputs that different message. What this does confirm, though, is that there doesn't seem to be a firewall or other communication problem. To try a slightly different test, can you: - stop the engine server service (just as you did in the last test); - do NOT start up the engine server in the DOS command window with the "java" command; - open up a DOS command window, and run the same telnet command as before ("telnet localhost 8088") Do you now get a different response? Does it fail to connect, or does it still connect and give you the blank screen? Thanks, - Bryan Shumsky Revelation Software </QUOTE> —- === At 26 JUN 2011 12:08AM Arsath Ahammed wrote: === <QUOTE>It says Could not open connection to localhost, on port 8088 connect failed. </QUOTE> —- === At 26 JUN 2011 02:07AM bshumsky wrote: === <QUOTE>Hi, Arsath. Good, that's the response we were hoping for; it means that nothing else is listening on that port and confusing things. You can go ahead and restart the engine server service. If you run REGEDIT to edit the registry where the OECGI3 settings are, and you _change_ the port number that's specified as the ServerPort value (for example, set it to 8089 instead of 8088), and then retry the request to INET_TRACE (http://localhost/examples/oecgi3.exe/INET_TRACE), does it produce any different output - a different error message, perhaps? I am trying to see if we can get back any response from OECGI3 at all - even an error response. At this point, I believe that the problem is most likely related to the configuration of IIS for OECGI3 execution. It looks like the OECGI3 quick start guide discusses installing into IIS 6.0 and above, which is different than the IIS 5.1 I believe you are running. What did you configure, then, in IIS 5.1 for OECGI3? In the IIS Manager, if you right-click on the virtual directory you created and choose "properties", what does it say in the Execute Permissions on the Home Directory tab? If you right-click in Windows Explorer (_not_ the IIS Manager) on the real folder that your virtual directory exposes, and choose "Sharing and Security", what is set in the Security tab? Thanks, - Bryan Shumsky Revelation Software </QUOTE> —- === At 26 JUN 2011 02:23AM bshumsky wrote: === <QUOTE>Another thing to look at is this Microsoft kb article: http://support.microsoft.com/default.aspx?scid=kb;EN-US;884764 It discusses a scenario under which IIS incorrectly returns the error message you're seeing, and a fix that you can download that might resolve it. </QUOTE> —- === At 27 JUN 2011 12:56AM Arsath Ahammed wrote: === <QUOTE>I tried changing port to 8089 in eserver.cfg and registry entry. Same response on running INET trace, debug did not reveal anything. I agree it is most likely the IIS server configuration for 5.1, I did not have to do any web extension settings or to allow a specific OECGI3 etc. When I right click on the virtual folder in IIS manager, I see execute permissions set to 'Scripts and Executables'. Through properties of the actual folder I see Web Sharing shows the alias I have given and permissions for everything except write and script source access. In the security tab, I have given myself full control and access to some other users. My registry settings are: For HKEY_LOCAL_MACHINE\SOFTWARE\RevSoft\OECGI3 ApplicationName: EXAMPLES EngineName: FileMode:1 FilePath: MultipleServers:0 OILocation: Password: ProcedureName:RUN_OECGI_REQUEST ServerPort:8089 ServerURL:localhost ShutdownFlags:1 StartupFlags:1 SysDownPage: UserName:EXAMPLES UserPassword: For HKEY_LOCAL_MACHINE\SOFTWARE\RevSoft\OECGI3\O4W ApplicationName: EXAMPLES FileMode:2 FilePath:\upload\ MultipleServers:0 Password: ProcedureName:RUN_OECGI_REQUEST ServerPort:8089 ServerURL:localhost SysDownPage: UserName:EXAMPLES </QUOTE> —- === At 27 JUN 2011 01:26AM Arsath Ahammed wrote: === <QUOTE>The hotfix did not help. I tried creating a virtual directory to another workstation running the oeserver. It says connection to port 8089 was forcefully rejected. The debug info showed enginecleanup only after I send cgi requests. I feel I could have missed out something elementary. </QUOTE> —- === At 27 JUN 2011 10:39AM bshumsky wrote: === <QUOTE>Hi, Arsath. This is actually a good change. The "forcefully rejected" message means that you are actually talking to OECGI3.EXE, and getting a response - which is _different_ than what you had been seeing. Please change the registry for this new virtual directory you created so that it points to port 8088, make sure the engine server is running, and try again to reach INET_TRACE. </QUOTE> —- === At 27 JUN 2011 05:08PM Jared Bratu wrote: === <QUOTE>Please check the IIS virtual directory security tab. The permissions should be "Read, Run Scripts, Execute". I suspect you may not have "Execute" selected. If this doesn't help the situation please email me jared@revelation.com for additional troubleshooting options. </QUOTE> —- === At 28 JUN 2011 05:45AM Arsath Ahammed wrote: === <QUOTE>Hi, The change of port just returned the same error but with a different port number, still forcefully rejected. I have given max permissions for the virtual directory in IIS and windows explorer. </QUOTE> —- === At 28 JUN 2011 09:10AM bshumsky wrote: === <QUOTE>Hi, Arsath. Since you're getting the "forcefully rejected" message, that means that we are now communicating with the OECGI3 routine, but that it cannot talk to the Engine Server. Are you sure you restarted the engine server, and that the port number that the engine server is listening on is what you entered into the registry? Thanks, - Bryan Shumsky Revelation Software </QUOTE> —- === At 06 JUL 2011 11:46AM Jared Bratu wrote: === <QUOTE>To wrap this up, I ended up working directly with Arsath and concluded that there was something particular to his computer that was preventing OECGI3.EXE from executing. We transitioned to a different system and the setup worked correctly. Below is a .BAT file that rill run OECGI3.EXE directly and display the results in notepad. You can use this same file to verify that OECGI3 and the OESocketServer are functioning without a web server. Execute the file from the same directory where OECGI3.EXE is located. rem begin rem testoecgi3.bat - call oecgi3 without web server

rem * set COMSPEC=C:\Windows\system32\cmd.exe set DOCUMENT_ROOT=f:/apache/htdocs set HTTP_ACCEPT=*/* set HTTP_ACCEPT_ENCODING=gzip, deflate set HTTP_ACCEPT_LANGUAGE=en-us set HTTP_CONNECTION=Keep-Alive set HTTP_HOST=localhost set HTTP_USER_AGENT=Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; COM+ 1.0.2204) set PATH=c:\temp set REMOTE_ADDR=127.0.0.1 set REMOTE_PORT=80 set SCRIPT_FILENAME=C:/Revsoft/OInsight/O4W/oecgi3.exe set SERVER_ADDR=127.0.0.1 set SERVER_ADMIN=email@domain.com set SERVER_NAME=localhost.domain.com set SERVER_PORT=80 set SERVER_SIGNATURE=Local OECGI Test set SERVER_SOFTWARE=NA set SystemRoot=C:\Windows set WINDIR=C:\Windows set GATEWAY_INTERFACE=CGI/1.1 set SERVER_PROTOCOL=HTTP/1.1 set REQUEST_METHOD=GET set QUERY_STRING= set REQUEST_URI=/o4w/oecgi3.exe/inet_trace set SCRIPT_NAME=/o4w/oecgi3.exe OECGI3.EXE ] test.txt start test.txt rem end

View this thread on the Works forum...