home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
OS/2 Shareware BBS: 35 Internet
/
35-Internet.zip
/
cern_os2.zip
/
readme.os2
< prev
next >
Wrap
Text File
|
1995-06-19
|
7KB
|
143 lines
*** cern httpd 3 OS/2-Version 1.01 *** (19.06.95)
This is a quick (and perhaps dirty) port of the nice
WWW-Server (and WWW-Library) by CERN to OS/2 2.x.
*** what's new?
This is the second release. It contains bugfixes for transmitting of
binary files (e.g. inline images for image maps) and for convenient
use under OS/2 which only supports uppercase environment variables.
This prevented the cern-WWW-Server to act as a proxy client, since
it asked for the existence of the environment variable "http_proxy"
which OS/2 (i.e. the standard shell cmd.exe) cannot provide. Now,
if it finds "http_proxy", "gopher_proxy", "wais_proxy" etc. to be
empty, it tries the respective variable with uppercased name.
Additionally, the linemode browser WWW has been ported to OS/2
(this has just been a recompile, it worked "out of the box").
See the file LineMode/readme for a short description of how to use.
The standard documentation can be found online at w3.www.org.
*** Credits
Tim Berners-Lee, Ari Luotonen and the other developpers of the WWW project!
(which started at CERN (info.cern.ch) and now resides at w3.www.org)
Eberhard Mattes for emx+gcc, emacs, and gdb for OS/2!
*** Requirements
To use this software you need some sort of TCP/IP stack, either
network interface card connected to a network (internet or just
internal), or modem or other means (SL/IP, PPP etc.). This means
that the DLL files tcp32dll.dll and so32dll.dll must be in your
LIBPATH.
It is tested with OS/2 2.10GA (german) and OS/2 Warp for Windows V3
(english), IBM TCP/IP 2.0 (CSD UN64092), and the IBM WebExplorer 1.01
as client.
Note: the WebExplorer upto version 1.01 does not support gatewaying
through the "proxy" entry field, i.e. if you fill out the respective
line, the request sent to the server becomes unusable.
*** Installation
I recommend running it off a hard drive formatted with HPFS or other
"nice" file system that suports long filenames. I did not bother
converting/renaming files or implementing algorithms that "shorten"
names to the sick FAT 8+3 file system and vc.vs. Be sure that you
have enough free space on your swap drive. I recommend that you
set the initial size of the swapfile to at least the amount of
"real" memory that is built into your computer (16 MB Ram -> 16 MB
initial size via "swappath=d:\swap 16384 16384" e.g.).
It *is* possible to configure different drives for e.g. the
configuration file and the data directory. I do not recommend this
way. Better install all the stuff on one drive and do not mess with
drive letters in the configuration file (Pass rules etc.). The way
drive letters are handled is not very nice (URL-access types and drive
letters are both recognized by the trailing colon ':') and I suspect
it may lead to strange results when someone sends a malformed
HTTP-request to the server (http:c:/config.sys or the like).
All you need is httpd_os2.exe and a configuration file, which may
consist more or less of a "pass /* /your/path/*" to test the
functionality. Of course, if you want to use sophisticated features
like document protection, caching or proxy-ing, there is a lot more to
configure. See all.conf, proxy.conf, caching.conf in the conf/
subdirectory.
For the first few tries RUN THE DAEMON IN VERBOSE MODE! This is
quite important for security and performance reasons. Do something
like "start /C httpd_os2 -v -r myconf.cnf". You may then stop the
server using ctrl-break or ctrl-c (strg-untbr or strg-c on german
keyboards). Later on I recommend using "detach httpd_os2 -r xy.conf"
since it saves some more ressources when running without terminal i/o.
*** Technical hints
The daemon uses the emx+gcc 0.9a#5 Library; thus, emx.dll has to be in
the LIBPATH. Be sure that there are no older emx.dll-files in
"earlier" locations referred to in the LIBPATH-statement. This is very
important because strange things (core dumps, file sharing/opening
problems) may happen if too old a version of emx.dll is used (I speak
from knowledge ...). Before running it in "production" mode check with
the enclosed emxrev.cmd ((c) Eberhard Mattes like the emx runtime
environment) whether there are other emx.dll files. It might run with
emx.dll 0.9a#3 (this fix introduced inheritance of sockets to child
processes) but I did not try. If you do not know what I mean just kill
all other emx.dll files. If you get an error message like "...\emx.dll
access denied" there are programs running that need and reference the
DLL currently. Find out that process and stop it (Emacs, gdb, emx+gcc
itself, the emxload server etc.). Afterwards unpack and move the
emx.dll to a "nice" place. It is no problem to update emx.dll! All
versions are upwards compatible, i.e. "old" programs always run with
a newer emx.dll.
Use the supplied simple configuration file httpd.conf which is
tested. If you want to use the sophisticated features like proxy and
caching, you are on your own.
*** Recommendations
If you have the ressources DON'T (I mean *don't*) run a caching server
on the same drive that contains your swapper.dat. This is very
important since the cern httpd does not check whether the file system
is full when writing files it wants to cache. Worse yet it does ignore
the settings of the maximum cache size (set it to 100 M and it will
happily write 130 M to the file system if there are this many
different requests). The cache size will only be correct after a
garbage collection.
This is a known bug (or "feature") of cern 3.0 and will probably be
corrected in the next release from w3.org.
If OS/2 cannot allocate room on this drive when it needs to, it will
fail, probably stopping with a "hard error" and you have to push
reset. This is quite disturbing because chkdsk needs to run for each
"dirty" drive, and this may take some time on large (especially quite
full) drives.
*** Full Documentation for cern httpd
Read the documentation for the daemon at
http://www.w3.org/hypertext/WWW/TheProject.html
or at
http://www.uni-giessen.de/www-doc/
(this is possibly outdated but convenient inside Germany).
*** Next version
This version is quite slow since it uses the fork() emulation of the
emx-C-Library and has to spawn off cmd.exe for each cgi-script. The
next release will make efficient use of OS/2 threads.
*** Who dunnit?
Please send bugreports or comments to
thomas.seeling@math.uni-giessen.de
or
ths@texbox.lahn.de