WWW Server
Overview
This goody implements a Web Server with additional functionality.
In addition to serving HTTP file requests, this server allows for
smalltalk applications to register themself as request handlers,
and thereby generating HTML responses dynamically (i.e. programmatically).
This dynamic HTML may be either generated directly by a smalltalk
object, or by executing embedded smalltalk found in a file document.
The
HTTPServer
consist of a merged functionality from the original ST/X
server, the PWS (Pluggable Web Server) code as provided with the Squeak PWS-Swiki,
and (new) compatibility code to support Comanche applications.
Features are:
- Supports multiple servers on multiple ports
- Regular file access via a configurable root directory (or multiple virtual roots)
- Configurable file caching
- Configuration via the Launchers settings dialog and/or via http.
- Keep alive connections (HTTP1.1)
- Basic and MD5 based digest authentication schemes
- Temporary (graphic) links for generated images
- SOAP callout mechanism
- Can be compiled into a standAlone webServer (see the projects/webServer directory)
- Pluggable Service Applications
Includes demos for
- hello world
- process monitor (i.e. monitoring ST/X)
- a very simple webShop application
- a sophisticated webSlideShow application
- PWS-applications:
Including:
- editable pages (everyone may edit)
- authorized pages (edit by authorized people only)
- embedded smalltalk pages
- ComSwiki (Comanche Swiki)
This includes:
- modern Swiki with flexible/dynamically changable styles
- administration via http
- STT (Smalltalk templates)
This provides functionality similar to php; html pages, which may contain embedded
smalltalk code (as processing instructions).
Documentation
See the documentation methods in HTTPServer;
Especially:
HTTPServer howToStart.
HTTPServer howToConfigure.
ComSwiki documentation found on Swiki-FAQ.
And, use the source - Luke.
There is a lot of informatio nto be found on the various swikis;
however, the following seems to be of special interest and is
therefore included here:
Examples
Start up the HTTPserver (see the launchers communications-settings dialog),
and your favourite browser.
As there are now quite a number of options and configuration parameters,
we recommend using the asdvanced settings dialog to configure the server.
However, the server may also be started and configured programmatically,
by evaluating:
HTTPServer startServer
or:
HTTPServer startServerOnPort:aPortNumber
Notice, that the HTTPServer cannot usually serve the default HTTP port (80),
because this is a system port, which cannot be served by non-priviledged users.
Therefore, the default port is 8080, which is a non-priviledged port
(you must run ST/X as superuser, or make it a setuid-root program,
in order to allow serving the priviledged port).
Do not forget to enter the correct port number in the browser
(i.e. enter the URL "http://hostname:port/").
Late note:
On many systems, the 8080-port is also in use (by the zope webServer).
So you may want to use 8081 or 8088 (sigh).
Depending on which features were enabled in the settings dialog,
the default page includes links to demonstrate features of the server.
Be aware, that the home page is just a pluggable service, and that it is
very easy to create your own one (have a look at the
WebHomePageForSTX class to see how).
Quick start:
Start the server on 8081:
Open a browser on it:
New services can be either be created by using the
STT (embedded smalltalk code) mechanism,
or by subclassing either
HTTPService
or
HTTPActionService
and defining the minimum required protocol there.
The difference is that an HTTPService is defined by at lease two URL-path components;
the first selects the service whereas the second is used as a message selector.
For protection, the message selector is validated by asking the service for its allowedMessages.
In contrast to this, HTTPActionService instances are always invoked via their process:
method (i.e. it has the freedom of simulating any document hierarchy below.
Typically, HTTPService instances are better suited for RPC-like action calls
(parametrized by additional arguments after the 2nd URL component),
whereas HTTPActionService instances are recommended if fileSystem hierarchies are to be
emulated.
STT examples are found in the "goodies/webServer/data" directory.
Examples of subclasses of
HTTPService and HTTPActionService are found via the browser.
Under Unix/Linux systems, the webServer can be built as a standalone (non-GUI) server application,
which can be started automatically via the init process (i.e. automatically, when the
operatingsystem is bootstrapped).
Makefiles and additional code for the standAlone server is found in the "projects/webServer"-directory.
To build the standAlone webServer executable, enter (at the shell-command level):
$ cd projects/webServer
$ make
After building, enter:
$ webServer --help
for usage information.
Licensing
This addOn package is NOT to be considered part of the base ST/X system.
It is provided physically with the ST/X delivery, but only for your
convenience.
Legally, it is a freeware or public domain goody, as specified in
the goodies copyright notice (see the goodies source).
No Warranty
This goody is provided AS-IS without any warranty whatsoever.
Apache as frontEnd
Text from Xerxes Rånby (found on Swiki-FAQ)
Apache as a "frontend" on top of Comanche using "reverse proxying" and "virtual hosting".
Here is a vhost entry for the apache 1.3 httpd.conf file
for a virtual domain called "http://www.foo.com"
I hope this will help.
dont forget to load your proxy and rewrite module, rewrite is used to handle some misplaced url's.
LoadModule proxy_module /usr/lib/apache/modules/libproxy.so
LoadModule rewrite_module /usr/lib/apache/modules/mod_rewrite.so
ServerName wiki.foo.com
#basic you will need something like this
ProxyPass / http://www.foo.com:8000/foo/
ProxyPassReverse / http://www.foo.com:8000/foo/
RewriteEngine on
RewriteRule ^/foo/(.*)$ /$1 [R]
#move of some files located in / on the original swiki
RewriteRule ^/comanche.gif$ http://www.foo.com:8000/comanche.gif [R]
RewriteRule ^/favicon.ico$ http://www.foo.com/favicon.ico [R]
#These rules makes apache handle heavy workload for uploads and button graphics.
#note these two "speedups" will not work on ComSwiki 1.3 for files with spaces in the filename.
RewriteRule ^/schemes/foo/(.*)$ http://www.foo.com/foo_scheme/$1 [R]
RewriteRule ^/uploads/(.*)$ http://www.foo.com/foo_uploads/$1 [R]
#Forces edit page requests to go to the slower wiki. if you never want to reveal your true swiki url remove this line.
RewriteRule ^/(.*.edit)$ http://www.foo.com:8000/foo/$1 [R]
Notice
The PWS code is no longer maintained (but kept there for backward compatibility).
We recommend using the HTTPService interface scheme for new applications.
Origin/Authors
HTTPServer is a merge of the original file-based ST/X httpServer,
the PWS (Pluggable Web Server) as provided by Squeak developers,
and (new!) the ComSwiki code.
Origin/Authors:
Squeak (PWS and ServerAction hierarchy))
Claus Gittinger (original HTTPServer, file access, caching & keepAlive)
Christian Penk (ComSwiki layer, refactoring into Services)
<info@exept.de>
Doc $Revision: 1.16 $