Direct Web Service

Web Service Port

In this box you can specify an alternative port, for example:

8080

or you can specify an IP address and port as in:

210.226.165.207:80

Web Crossing supports multihoming on platforms that allow multiple IP addresses, such as most Unix systems. This allows you to run multiple Web Crossing servers in Direct Web Service Mode, all using Port 80. This feature is also called IP Aliasing.

You may also enter a list of IP-Address:Port pairs, separated by blanks, commas or newlines. All listed address:port pairs will be listened to by Web Crossing.

Maximum number of simultaneous requests

You can modify this number to help with your load balancing. The default value is 64, which means that Web Crossing will handle up to 64 simultaneous requests from browsers. Increasing the number will increase the number of users handled simultaneously at a busy site.

Beware! If you make this number too large, you can actually cause the serving time per request to increase, resulting in slow serving. If your Internet connection is slow (for example, 56K ISDN) you may actually want to decrease this value in order to handle requests more quickly. In other words, there is always a trade off between bandwidth and the number of requests you can handle effectively in a fixed period of time.

Directory for data files

This is the "root" directory for serving ordinary web pages. If you leave this entry blank, then your root directory will be the same as your Web Crossing server directory. This is not recommended.

One common setting is:

./html

which means that all your ordinary web pages are found in the html directory inside your Web Crossing server directory.

You can also specify absolute pathname in your file system. For example:

/usr/home/webxpages

Note that you must assure that the specified directory actually exists in your file system.

In the MacOS version you would specify

:/html

instead of ./html (a colon is used to separate directories on the Mac).

This defines a "script name" that is used in building Web Crossing URLs. If left blank the default script name is

WebX

In most cases there is typically no need to change this entry. One reason you may want to change it is if you are porting over a webx.db database from another system with a different script name. Rather than change the contents of the database, you can just change the script name here to match up. For example, if you port a webx.db database over from a Web Crossing server that had a script name

cgi-bin/webx

you can change the script name here to correspond to that.

URL for top-level access

When users access your Web Crossing server you can specify the top-level page they first see by the entry here.

For example, to have users go directly to the top-level of the discussion boards enter:

/webx

here (which is the default).

To have users go to the location specified by the unique ID .ee6b61b you can enter:

/webx?.ee6b61b

If your Web Crossing server is listening to more than one port then you can also specify different top-level access points for different ports. For example, to have people accessing via port 80 go to the top level, but have people accessing via port 81 go to the location specified by the unique ID .ee6b61b, you can enter:

210.226.165.207:80=/webx
210.226.165.207:81=/webx?.ee6b61b

You can specify any Web Crossing action URL, having different people accessing via different ports accessing not only different locations but also performing different actions, such as running different customized macros.

Common log filename

If you specify a filename here then an access log is maintained in the Common Log file format. There are many third-party analyzing tools that take Common Log files and produce statistics about the use of your system.

If you leave this item blank then no access log will be recorded.

This feature is only available when running in Direct Web Service mode. If you are running as a CGI then you must rely on the external web server's log capabilities.

This feature should not be confused with the Log File feature in the Sysop Control Panel. That Log File feature is available for both Direct Web Service mode and CGI mode and provides basic logging of requests and the ability to perform detailed TCP/IP logs for diagnostic purposes.

Include referrer and user agent in the common log output

One of the optional features of the Common Log format is the ability to record the referrer (the URL from which the user came) and the user agent (the type of browser that was used for access. If this box is checked, both the referrer and the user agent are recorded in the Common Log file.

The referrer is particularly useful for analyzing where your users are learning about your site. The user agent shows computer platform (Windows, MacOS, etc.) in addition to browser type, which is also helpful information when designing your web forum pages.

Web service to FastCGI routing

FastCGI is, as the name implies, a fast alternative to ordinary CGI. Almost the same speed as Direct Web Service is maintained. Your Web Crossing server can act as a front end server to a set of other servers capable of communicating via FastCGI.

The most obvious use for this is if you have multiple Web Crossing/Platinum servers running on a large site, mirroring a webx.db. For load balancing purposes, you want to route incoming users in a round-robin fashion among the different platinum servers. Web Crossing can be used as a software round-robin server.

The Port for incoming HTTP requests specifies an ip-address:port pair for receiving routing requests, such as:

1.2.3.4:80

If your Web Crossing server is not performing routing to a FastCGI server then you can leave this blank.

The number of simultaneous HTTP connections specifies how many incoming routing connections can be handled at the same time.

The Destination FastCGI Servers are are list of servers to which requests are routed in a round-robin fashion, for example:

3.4.5.6:1118
3.4.5.7:1118