The server status form
The server status form serves as the configuration console of the currently running server application. It shows the current settings for the server and allows you to modify them on the fly and save the values persistently.
Here's what the various fields mean:
The startup path shows the location that the server is currently running from. This path is set the first time the server is run based on the server's physical disk location and then stored in the registry. Everytime the server starts this value is read from the registry and the server path (SET DEFAULT/CD) is then changed to the specified directory.
Typically this path will always match the server's physical location on the disk, but in some special situations you'll want to override this path to a different location. For example, when running a file based Web Connection server on another machine it makes sense to change the path to the remote machine so that all the configuration and data files can be found with relative paths.
In any case you can change this setting to re-write the value into the registry.
Maps to wwServer::cTempFilePath
Temp Files, Timer Interval and File Template - File based operation only
These settings are specific to operating Web Connection in file based mode and determine where and how the file messages are processed by WWWC. The temp file path shows the path where the server expects request files to coming in from the Web server. This setting should match what the Path= setting says in wc.ini. The timer interval determines how often the file based server polls for new request files. The shorter the interval the faster the turnaround. The default is 200 milliseconds. It's not recommended that you set this value smaller than 75 unless your server is super busy all the time. The Template identifies what type of files the server is polling for in the temp directory. Again this value must match the active wc.ini Template setting.
This flag determines whether the server window displays each request in its window.
Maps to wwServer::lShowStatus
Log to File
Determines whether Web Conection's request logging is turned on. By default Web Connection logs every request to a DBF file, RequestLog.dbf by default. This flag enables or disables this logging.
Maps to: wwServer::lLogToFile
The script mode determines how Web Connection interprets WCS script files. You can choose between interpreted and compiled operation. Scripts can be compiled on the Admin page.
Maps to: wwServer::nScriptMode
A very useful feature of this form is the ability to cause Web Connection to capture request output and then display it to you for review. You can capture both the Request input (form and server variables) as well as the complete HTML output generated by the server.
To do so use the options on the bottom of the status form:
The Save Request Files checkbox causes every request to save its inputs and outputs to a static text file in your temp directory. The files are static and are called TEMP.HTM and TEMP.INI. This feature is meant as a debugging mechanism so it's not advisable to have this option enabled in a production environment.
Once the checkbox is set run a request. Come back to this form and click on the Display Request button which produces the following form:
These windows give you good insight into the last HTTP request that was fired. You can see the raw HTTP request data that was sent from IIS both in raw form as well as a parsed version that breaks out each of the request values for easier reading by key value pairs. The Response page shows the full HTTP response including the HTTP headers that the Web Connection server sent out.
Viewing the request data provides extremely useful debug information that tells you exactly what a client request posted to the server. This is very useful for debugging HTML form problems as well as things like Cookie and Authentication issues where logins apparently fail. This data is provided straight from the Web server so if it's not here, it didn't get sent!
Save Request files is a useful debugging tool but it writes output to a disk file and while it does it locks the file. This means requests are locking and get blocked while each instance completes writing out the new data. In busy sites this can cause locking errors in your application.
In production applications always turn this setting off unless you are explicitly debugging a live application.
Comment or report problem with topic