Back to HTTPServer Main Index
HTTPServices are objects which are responsible for handling http requests.
They register themself at a server under a so called linkName (or multiple link names).
Typically, the linkname is the top-component of an URL path - for example: "/foo".
For any incoming request, the http-server selects the service based on the requests URL
and forwards the request to the service, which has to generate a response
(typically, HTML, XML text or bitmap images).
Due to the historic evolution of the web server, there are two different schemes for service handling:
HTTPSelectorService
to support applications based in the PWS (pluggable web server) framework
which receive individual messages, based on a component in the URL
HTTPActionService
to support applications based on the Comanche framework
where a single processing method is invoked for all requests.
In order to allow for easy migration of applications based on these packages,
the ST/X webServer supports both schemes.
However, we think that the HTTPActionService scheme (single processing method)
is better and more flexible, and we therefore recommend using that for new applications.
HTTPSelectorService
HTTPSelectorServices must provide a list of allowed service selectors
and a default service selector.
For any incoming request, the URL component AFTER the linkName is extracted and taken
as a message selector. I.e. if the URL is "/foo/bar", the service registered under the
"/foo" linkName gets a "bar:" message.
If the URL is the linkName alone (i.e. no component after the linkName),
the default selector is used.
If a selector is not allowed, the server responds with an "Illegal Message" response.
HTTPActionService
HTTPActionServices will always receive a "process:" message, with the request as argument.
They are free to (and actually responsible for) interpreting the URL and dispatching to
any internal method.
Presents a list of available services (all subclasses of the HTTPService class).
Use the down arrow button to add the selected service to the server (i.e. to register).
Presents a list of all registered services for the server.
Every service has the following properties:
- Realm
Realm for authorization. If non-blank, the service can only be invoked by users which
authenticate themself as belonging to that realm (group).
If blank, everyone is allowed to invoke that service.
Be aware, that the HTTP protocol supports multiple authentication protocls which
differ in complexity and security. For critical applications, we highly recommend to
disable basic authentication, because it is *very* insecure and easy to attack.
- Allow Robots
Allow or disallow robots to access the service. If allowed, robots and crawlers
(such as google or other search engines) can access and index the pages of the service.
For highly dynamic and/or private services, we recommend to disallow robots.
The default is: disallow.
- Visible (in Home Page)
Set/Clear the visible in home page aspect of a service.
The ST/X home page service will automatically generate links for services
which have the visible attribute set.
- Reply Presenter
Used to display the service output written via nextPut: nextPutAll: or reply: in a special frame.
If you select "None" the server default reply presenter (which does not generate any decoration)
is used for the service.
You can create your own representer class to wrap generated pages into
a corporate identity-layout.
For more information, see Server Configuration.
- EmptyDocumentReplyPresenter - data is wrapped into the body of a legal html document
- ExeptReplyPresenter - an simple eXept reply presentation frame
- PlainReplyPresenter - as is (for debugging only)
- Link Name(s)
The link name(s) under which the service is(are) registered.
Each link name has to started with a "/"-Character.
Linknames are not limited to the top in the URL hierarchy;
you can specify a deep path (such as "/foo/bar/baz") to include the service
below another service in the URL document tree.
Service Request Context
To aid in programming threadsafe services, the HTTPServiceRequestContext-class
provides an interface to be inherited from.
This allows you to store variables on a per request basis.
For every request an instance of your subclass is created where the instance variable request is set.
Before passing through the service, initialize is called where you can do your own initialization of
your variables. This enables you to have request dependent state. At the end of the request release is called.
Redefine the class method requestContextClass: for your service that
returns your subclass of HTTPServiceRequestContext.
Reply Presenter
The reply presenters repsonsibility is to wrap a generated HTML-page and generate
a common frame around it for a nice common style.
Already provied are the default presenter (which generates nothing and leaves the pages as-is)
and the exept reply presenter, which generates a greenish exept-style frame with home-button.
This is mostly provided as an example.
To create your own Reply Presenter, create a subclass of ReplyPresenter.
and implement the required protocol (use the browser - luke).
Useful Helper Services
Even programatic services (such as the HomePageService, STT- or Swiki-Services)
often generate references to common files such as icons, bitmap images etc.
Typically, a FileService is used for this and automatically installed/deinstalled with the
service.
In addition, other useful services are provided by the HTTPUtilityService;
Currently, this provides an accessCounter service, but more utilities are probably to
be added in the future.
Copyright © 2003 eXept Software AG, all rights reserved
Doc $Revision: 1.4 $ $Date: 1997/08/07 15:06:09 $