Xitami 1.3c
Xitami 1.3c
| iMatix home page | Xitami home page | << | < | > | >>
You need a TCP/IP winsock.dll. And it has to work. And it has to be configured correctly. If you have any kind of difficulty running Xitami or connecting to it, use the PING command to debug your TCP/IP configuration. First, use 'ping 127.0.0.1' to check that TCP/IP is working. Then, use 'ping localhost' to check that winsock.dll is working. Next try ping with the system name that Xitami displays. Then, try this command from another system. All these must work before you can use Xitami.
Xitami accepts connections on any available IP address. If you have multiple IP addresses, Xitami accepts connections on all of them. More usually under Windows you have only one network card, only one IP address.
Xitami gets its host name from the operating system - i.e. Windows. Your IP address is not something that Xitami can change or choose. Check your network configuration and if neccessary, ask your network administrator. Note the next question about PPP connections... The same applies to the hostname that Xitami displays. This is the name of the system as supplied by Windows. You can change this in the network control panel.
You're using Windows? Check the tcp/ip configuration; your system is probably called 'default'. ':777' is the HTTP port you asked for, presumably.
Xitami gets its name from the operating system. Check the TCP/IP configuration and especially the computer name. You should be able to test this using the 'ping' command in a DOS box. Eg. 'ping mysystem'.
Presumably your problem is that the PPP connection is allocating IP addresses dynamically. This makes it hard for anyone to know where your machine is in advance. Ask your ISP if you can get a fixed IP address - though the chances are slim. You can use ping to find-out what your current IP address is. Xitami shows you the local system name - use that as an argument for ping.
Set the server:translate option to 0. When this is 1, Xitami sends back a URL to the browser that includes the server machine name. But when the server is on a PPP link, this often can't be handled by the browser. When the server:translate option is 0, Xitami returns a numeric IP address, which the browser will be able to handle.
Ping is a good test to see if your computer name can be translated correctly. If you're on the Internet, you need to ask your Internet service provider to make the necessary DNS entries. On your own PC, you can edit the 'hosts' file in the Windows directory. The file 'hosts.sam' is a sample that you can rename to 'hosts'. Then, add your machine name and 127.0.0.1. This may not always work; address translation may require that you are actually on-line. For instance, I can 'ping 127.0.0.1' at any time. When I try to 'ping localhost', I get the TCP/IP connect dialog. I can Cancel this, and then 'ping localhost' works. But to ping my machine name, I must be online.
No. Not yet, at least.
Yes, but it will be late in 1997. The basic problem with CGI under Win 3.x is that the standard input/output mechanisms do not work and must be handled by reading and writing files (simple but not portable). We will support the so-called WinCGI protocol.
The options on the Xitami control panel (webpage and CGI directory, and HTTP port) are not taken from the .cfg file except when you start using virtual hosts. This may change in a later release.
Under Windows 95, you cannot run a 16-bit CGI program that is on a path with 'long filenames'.
Under Windows NT, you cannot run 16-bit CGIs at all, due to a limitation of the Windows 32-16 bit interface. We're working on this.
A decent web server like Xitami does not need large amounts of memory or a blazing CPU. You can happily serve a group of several hundred users from a 486 PC with 16Mb memory. If you want to run heavy CGI programs, you'll need a faster system. Also, a fast hard disk is a good idea. And of course, any server is limited to the speed of the network. Given a fast hard disk and a fast network, Xitami will be able to handle several hits per second even on a slow 486 PC, and dozens of hits per second on a fast Pentium. (One hit per second is equivalent to about 20 users actively browsing, at the rate of a page per minute where a page requires about 3 accesses. If an average user browses for an hour a day, one hit per second thus translates into 100-150 users.) We like Windows 95 as a server system, given that is cheap to buy, and is a robust 32- bit solution.
When idling, xiwin16.exe spends most of its time waiting for incoming socket events. Under Windows 95 or NT, a 16-bit program that is waiting for socket events looks like it is sitting on the entire CPU. Maybe it is. Anything can happen in this business. However, as far as we can tell, the program really is idling, and does not slow-down the system. If this bothers you, move to Windows 95, and run the 32-bit version of Xitami. This uses Windows threads (as well as its own internal multithreading) to reduce CPU consumption to 1% or less when idling.
No; we use Windows multithreading (as well as our own multithreading), and this will not work under 3.x.
Xitami reports 'Not Found', and any other 3xx, 4xx, or 5xx return code as an error on its control panel.
Use a web site counter like this one for Windows 95.
The ~username syntax is a Unix thing; Unix usually translates ~username into the home directory for a user. If you run Xitami under Unix, this will work automatically. Under Windows, ~username means nothing; there are no user home directories. However, you can get much the same effect by creating a subdirectory for each user underneath the webpages directory. Then, you use the syntax:
http://ipaddress/username/
Correct. This is part of some fiendish plan for world domination, or possible just a bug in the Win95 console interface that works by passing a secret character to the conagent.exe program (so that only Windows can start a console program). In OSR2 this secret character is filtered by the codeset translation tables and changed to something that conagent.exe rejects. So, patch your Cyrillic codeset tables, folks! [We are not making this up; this is actually true, though admittedly not a very frequently-asked question.]
Xitami should build on: IBM AIX, Digital UNIX, HP/UX, Sun Solaris, SCO OpenUnix, SCO OpenServer, Linux. Anything else is unexplored territory. Drop us a line and we'll try to help.
Oh goodness, there must be hundreds of places to get a good answer to this question. Look at the example programs in the cgi-src directory.
If you have enabled Keep-Alive in the server, every HTTP response must contain a valid 'Content-Length' header. When Xitami builds the HTTP header itself, this works fine. But you can build your own HTTP header in a CGI program -- see the testcgi1.c example. This is difficult to combine with Keep-Alive, unless you carefully calculate the size of the generated text and generate your own Content-Length header.
We have a prototype interface called WTP (web transaction protocol) in place. This looks like CGI mixed with MVS/CICS. We are also developing a separate plug-in technology (WSX, "web server extension") which should be working by the late summer (that's 1997). It will work much as the other xxAPIs, but within the multithreaded SMT model.
There are various things that will stop a Perl script from working. The first thing to check is that you have installed Perl (yes, some people don't realise that this is necessary) and that you can run the script from the command line (to catch syntax errors). Next, make sure that Perl is on your path, and that the first line of the script looks like this: "#! perl". You can also specify the full Perl pathname: "#! drive:\path\perl.exe".
You must let Xitami know that the script is executable, rather than a text file to be sent to the browser. Make sure the script starts with the magic '#! perl' line.
Increase the cgi:timeout value.
Make sure your directory is password-protected. You can put the CGI script at any level under a directory like 'private', so long as the URL contains '/cgi-bin' somewhere.
You can redefine this by changing the server:cgi-url option. As usual, modify this in custom.cfg, not xitami.cfg.
Of course. On Windows, use windmail.exe. This works just fine.
You can do this quite simply by starting two copies of Xitami. We do this quite often; the advantage is that you can get the effect of multiple hosts (different document roots) without playing with the DNS system. Otherwise, you have to define DNS entries that map several different names 'www1.here.com', 'www2.here.com' to the same IP address, then base the virtual hosting on the different names. Either way is okay; Xitami is so small that running two or even a dozen copies will not stress a system.
You can use one computer as a server, and one as a client if you like, but you can also use the same computer as client and server. Xitami is so small and fast that you can develop Java or CGI programs on the same system you test them on, and you will not notice any slow-down. This is also a simpler way of working than always copying your webstuff to another machine. Just set your Xitami cgi-bin option to point to the directory where you build your executables, or the webpages directory to your HTML directory root.
You can switch these off; set serverlog:filename to "NULL".
This is just another way of calling the portable, command-line version of Xitami. Usually we use this term in contrast to the Windows GUI versions of the web servers, which provide a graphical control panel for the web server.
This is a temporary situation: we plan to release an update in 1998 that uses encoded (hashed) passwords for better security. The password file itself is not accessible to browsers, unless you specify the Xitami root directory as its webpage directory.
There are many freeware and commercial logfile analysers; the Xitami access logfiles are NCSA/HTTPd compatible and thus compatible with most logfile analysers. The Xitami.log file is used for server messages and thus not suitable for analysis.
Let's say you installed Xitami in c:\servers\xitami. Then, the main webpage directory will be c:\servers\xitami\webpages. An URL like 'http://dynamic210.adelphia.net/Joe' is taken to mean something like: 'http://dynamic210.adelphia.net/Joe/index.htm', which would be a file: 'c:\servers\xitami\webpages\joe\index.htm'. You can also use default.htm, and you can change the main webpages directory to be somewhere else if you want. Under Windows 95 and NT you can make each subdirectory shareable separately, so that users can update their pages but not mess with other files. You can also use aliases, especially if users' pages are on different disks.
Any URL containing /cgi-bin/ is treated as a CGI directory. So, Joe can put his web pages in "c:\servers\xitami\webpages\joe\" and his CGI programs in "c:\servers\xitami\webpages\joe\cgi-bin\".
Change the custom.cfg file server:defaultn options. You can specify anything you like, but start with 'default1'.
You cannot set your system hostname here. You have to get this working at the level of TCP/IP itself, e.g. by using the hosts file or a domain name server (DNS). However, you can specify the hostname that's used in redirected URLs, and this is important for virtual hosts.
You have to do two main things:
This is usually only worth doing if you have your own system, permanently connected to the Internet, or you want to rent a 'virtual host' on someone else's system. In the first case, your ISP can usually help set things up. In the second case, the virtual host provider will be able to help.
Make sure the server:keep-alive option is enabled. Add lots of RAM to your system and make sure this is available to your operating system disk cache. Put your web site onto a RAM disk. Don't use lazy, slow CGIs, especially ones that search large databases.
These are some of the upcoming changes we are working on:
No dates have been released for any of these.
| << | <
| > | >>
| Contents
| Installation
| Administration
| Configuration
| Using CGI
| Image Maps
| Virtual Hosting
| A Beginner's Guide
| FAQ
| Technical Implementation
| Getting Support
| Release History
| License Agreement
Designed by Pieter Hintjens © 1997 iMatix