HTTP Modules

Access to the Server WebAdmin Interface Pages
Access to the Domain WebAdmin Interface Pages
Access to the WebUser Interface
Access to Personal File Sites
Access to Calendar and Tasks data
Configuring the HTTP modules
Routing
Common Gateway Interface (CGI)

The CommuniGate Pro HTTP Admin and User modules implement the Hypertext Transfer Protocol via TCP/IP networks.

The CommuniGate Pro Server uses the HTTP Admin module:

to provide access to the Server WebAdmin (Administration) Interface pages.
to provide access to Domain WebAdmin (Administration) Interface pages.

The CommuniGate Pro Server uses the HTTP User module:

to implement the WebUser Interface to user Accounts and Mailing List archives.
to provide access to Personal File Sites.
to provide access to Common Gateway Interface (CGI) programs.

The CommuniGate Pro HTTP modules support various authentication methods, including the GSSAPI, Kerberos, and Certiciate methods implementing the single sign-on functionality.

Access to the Server WebAdmin Interface Pages

The Server Administrator can use any Web browser application to configure and to monitor the Server remotely, using the Web (HTML) forms.

The authentication schemes supported with the HTTP protocol protect the WebAdmin pages from an unauthorized access. In order to access the WebAdmin pages, the user should provide the name and the password of a CommuniGatePro account with required Server Access Rights.

By default, the HTTP Admin module accepts clear text TCP/IP WebAdmin connections on the port 8010 and secure (SSL/TLS) connections on the TCP port 9010.

To access the WebAdmin pages, the Server administrator should use the following URLs:
http://domain.com:8010

https://domain.com:9010
where domain.com is the name of the main server domain or its alias, or the IP address of the CommuniGate Pro Server.

Access to the Domain WebAdmin Interface Pages

If the CommuniGate Pro Server supports several Secondary Domains, the same port can be used by the Domain Administrators to access the Secondary Domains settings and account lists.

A domain administrator should access the server using the following URL:

http://sub.domain.com:8010
https://sub.domain.com:9010
where sub.domain.com is the name of the secondary domain to administer.

The server will ask for a user (Account) name and a password, and if the specified Account has the Domain Administrator access right, the list of the Domain Accounts is displayed.

Sometimes this URL cannot be used. For example, a secondary Domain may have no DNS A-records (only MX records). To access such a Domain, its Domain Administrator should use the following URL:

http://domain.com:8010/Admin/sub.domain.com/
where:

domain.com is the name of the Main Server Domain or its alias, or the IP address of the CommuniGate Pro Server.

sub.domain.com is the name of the Domain to access.

Server configuration errors can cut you off the Server WebAdmin Interface, if all your Server IP addresses and DNS names are assigned to secondary Domains. To access the Server WebAdmin Interface, use the following URLs:

http://sub.domain.com:8010/MainAdmin/
https://sub.domain.com:9010/MainAdmin/
where sub.domain.com is any name pointing to your Server computer or any of its IP addresses.

Other Domains can specify your Domain as their Administrtor Domain. Your Domain WebAdmin Login page provides a list of those Domains, so you can open their WebAdmin Interfaces. Remember that you should login using your full Account name (yourAccountName@yourDomainName) when accessing other Domain WebAdmin pages.

Access to the WebUser Interface

CommuniGatePro users can connect to the CommuniGate Pro Server with any Web browser (via the HTTP protocol) to manage their accounts, to browse their mailboxes, to read, copy, delete, forward, and redirect messages, to move messages between mailboxes, to compose and submit new messages, etc. This CommuniGate Pro component is called the WebUser Interface.

Registered users and guests can also use this component to browse mailing list archives.

By default, the HTTP User module accepts clear text TCP/IP connections on the TCP port 8100, and the secure connections - on the TCP port 9100. If your Server does not have to coexist with some other Web Server on the same computer, it is recommended to change these port numbers to 80 and 443 - the standard HTTP and HTTPS port numbers.
In this case your users will not have to specify the port number in their browsers.

Access to Personal File Sites

CommuniGatePro users can have their personal File Sites. See the File Site section for the details.

The URL for the account@domain personal File Site is:
http://domain:port/~account
where port is the WebUser port (8100 by default).

The list of files on that Personal File Site can be seen at:
http://domain:port/~account/index.wssp

You can also use the CommuniGate Pro Router to access Personal File Sites with domain-level URLs. See the Routing section below.

You can specify an alternative Personal File Sites prefix in the Domain Settings. That setting can be an empty string, in this case Personal File Sites can be accessed using the following URLs:
http://domain:port/account/.

Access to Calendar and Tasks data

The CommuniGate Pro HTTP User module allows groupware applications (such as Apple iCal) to retrieve data from the Calendar and Task mailboxes in the iCalendar format. This operation is often called subscribing to Calendar data. The module also allows groupware applications to rewrite the mailbox content with data in the iCalendar format (to publish calendaring data).

The URL for Calendaring data is:

http://servername:port/CalendarData/mailboxName

where port is the WebUser port (8100 by default). If the mailboxName ends with the ics file extension, the server removes that extension.

All Calendaring data requests must be authenticated: the user should specify the Account name and password. The Account and its Domain must have their WebCal Service enabled.

If the user Domain Name or Domain Alias name is mail.company.com, the WebUser port is 80, and the mailbox name is Calendar, the access URL is

http://mail.company.com/CalendarData/Calendar

http://mail.company.com/CalendarData/Calendar.ics

Any Calendar-type or Task-type mailbox can be accessed this way. To access a mailbox in a different Account, the full mailbox name should be specified:

http://mail.company.com/CalendarData/~username/Calendar.ics

The authenticated user should have proper access rights to retrieve and/or modify data in mailboxes belonging to other users.

The HTTP module supports the following HTTP operations for the /CalendarData/ realm:

GET/HEAD: the mailbox is parsed, and all items containing iCalendar information are retrieved as one VCALENDAR object with VEVENT and VTODO elements. If the mailbox is a foreign mailbox, the authenitcated user must have the Select access right for that mailbox.
DELETE: the mailbox is parsed and all items containing iCalendar information are removed. If the mailbox is a foreign mailbox, the authenitcated user must have the Delete access right for that mailbox.
PUT: the HTTP request body is parsed as a VCALENDAR object. All parsed VEVENT and VTODO elements are added to the mailbox as separate items. If parsing of any element failed, no item is added. If the mailbox is a foreign mailbox, the authenitcated user must have the Insert access right for that mailbox.

Some applications do not support the DELETE method. These applications expect that the PUT operation removes all previous information from the Calendar mailbox. To support these applications, use the CalendarDataDel realm instead of the CalendarData realm, or include the DeleteAll=1 parameter into the URL. In this case each PUT operation will be preceeded with a virtual DELETE operation removing all exiting iCalendar items from the mailbox.

Configuring the HTTP modules

Use any Web Browser to connect to the Administration Port on your Server, and open the Access page in the Settings section.

Serving HTTP Admin Clients

Log:
Channels:		listener

Serving HTTP User Clients

Log:
Channels:		listener

Log Level: Use this setting to specify what kind of information the HTTP module should put in the Server Log. Usually you should use the Major or Problems (non-fatal errors) levels. But when you experience problems with the HTTP module, you may want to set the Log Level setting to Low-Level or All Info: in this case protocol-level or link-level details will be recorded in the System Log as well.
The HTTP Admin module records in the System Log are marked with the HTTPA tag.
The HTTP User module records in the System Log are marked with the HTTPU tag.
Channels: This setting is used to limit the number of simultaneous TCP/IP connections the HTTP module can accept. Most browsers open several connections to load an HTML page and all embedded pictures, so do not set this limit to less than 5, otherwise some browsers may fail to download embedded graphic objects.
listener: Follow this link to open the HTTP Admin Port or HTTP User Port listner settings. There you can specify the TCP port number(s) the service should use, the interfaces to use, and other options.

If the CommuniGate Pro Server computer runs some other Web Server application, you should specify a port number in the "secondary range" to avoid conflicts with that other Web Server application. Usually the "secondary" Web Servers use ports numbers in the 8000-8100 range. If you set the port number to 8010, you will be able to connect to your server by entering http://xxx.yyy.zzz:8010 in your Web browser, where xxx.yyy.zzz is the exact domain name (A-record) or the IP address of your server.

Additional HTTP protocol options can be found on the WebUser page in the Setting realm of the WebAdmin Interface:

HTTP Options

Advertise `Basic` AUTH		Advertise `Digest` AUTH
Advertise `NTLM` AUTH		Advertise `Negotiate` AUTH

Request Size Limit:		Support `Keep-Alive`
	Scan Large Requests

Advertise Basic AUTH, Advertise Digest AUTH, Advertise NTLM AUTH, Advertise Negotiate AUTH: If these options are enabled, the Server will inform browsers that clear-text (Basic) or secure (Digest, NTLM, Negotiate/SNEGO) authentication methods are available. If you plan to connect to the WebAdmin Interface via clear-text (non-encrypted) links over the Internet, you may want to enable these options. Different browsers work differenly when these options are enabled. Some may fail, some may still use the clear-text (Basic) authentication method, so enable these options only if needed.
Note: the GSSAPI (Kerberos) authentication methods become available when the Negotiate AUTH method is enabled.
Request Size Limit: This setting limits the maximum size of an HTTP request the Server accepts. You may want to increase this limit if you want to allow your users to upload larger files and/or to attach larger files to messages composed using he WebUser Interface.
Support Keep-Alive: If this option is enabled, the CommuniGate Pro supports the Keep-Alive protocol feature, so a user browser can retrieve several files using the same HTTP connection. Some browsers do not implement this function correctly and they may have problems if this option is enabled.
Scan Large Requests: If this option is disabled, and the size of a HTTP request to be received exceeds the specified limit, the Server sends an error response and closes the connection. Many browsers do not display the error response in this case. Instead, they display a generic "connection is broken" message.
If this option is enabled, the Server sends an error response back and receives the entire request (but it does not store it anywhere). The user browser then displays the error message.

The HTTP modules set the MIME Content-Type for every object they send. To detect the proper Content-Type for plain files, the modules use the file name extension and the following built-in table:

File Extension MIME type

html text/html

txt text/plain

gif image/gif

jpg image/jpeg

You can extend this table by specifying additional file name extensions and corresponding MIME Content-Types:

Routing

The HTTP modules use the Router to process all address it receives. But unlike other Access modules, the HTTP modules often deal not with complete E-mail addresses, but with domain names only.

When a request is received on the WebAdmin port, the HTTP module should use the domain name or the IP address specified in the URL to decide which Domain Administration pages to display.

When a request is received on the WebUser port, the HTTP module should use the name specified in the URL to decide which Domain (its login page, mailing lists, Personal File Sites, etc.) to access.

In order to support all types of CommuniGate Pro Routing features (Router Table, Domain Aliases, IP Address to Domain Mapping, etc.), the HTTP module composes a complete E-mail address LoginPage@domainname (where domainname is the domain name specified in the request URL), and then it processes this address with the Router:

If the LoginPage@domainname address is routed to any module other than LOCAL, an error is returned.
If the LoginPage@domainname address is routed to the LOCAL module and local part of the resulting address is still LoginPage, then the domain part of the resulting address is used to open the proper CommuniGate Pro Domain.
If the address is routed to the LOCAL module, but the resulting username is not LoginPage, the Personal File Site of the addressed Account is opened. If the resulting address has a local part, then the Personal File Site subdirectory with that name is opened.

Samples (Router Table records, domainA.com is a CommuniGate Pro Domain):

mail2.domain.com = domainA.com: When the http://mail2.domain.com/ URL is used, the <LoginPage@mail2.domain.com> address is routed to <LoginPage@domainA.com> address, and the domainA.com Web Interface is opened.
<LoginPage@mail2.domain.com> = user@domainA.com: When the http://mail2.domain.com/ URL is used, the <LoginPage@mail2.domain.com> address is routed to LOCAL account user@domainA.com, and the user@domainA.com Personal File Site is opened.
<LoginPage@mail2.domain.com> = subDir@user@domainA.com.domain: When the http://mail2.domain.com/ URL is used, the <LoginPage@mail2.domain.com> address is routed to the LOCAL account user@domainA.com with the subDir local address part, and the subDir directory of the user@domainA.com Personal File Site is opened.

Common Gateway Interface (CGI)

The HTTP User module can start CGI programs and scripts. To access a CGI program, the /cgi-bin/programName URL should be used, and the programName program should be placed into the CommuniGate Pro CGI Directory.

Use the WebAdmin Interface to open the WebUser page in the Settings realm:

CGI Directory

Enter the name of the server system file directory where your CGI programs are located. If that directory is inside the CommuniGate Pro base directory, then you can specify its relative name, otherwise specify the full path to that directory. The CGI Directory should not have any subdirectories.

File Extensions

While some operating systems (such as Unix) can start various interpreter-type programs/scripts by starting the proper interpreter, other operating systems require that the interpreter program is started explicitly. The CommuniGate Pro Server supports those operating systems by allowing you to specify the name of the interpreter program for certain file extensions. As a result, when the CommuniGate Pro Server needs to start a program or script with the specified extension, it forms the OS-level command line by prefixing the program/script name with the specified interpreter program name.
In the above example the Server will process the /cgi-bin/script.pl URL by executing the

Perl.exe script.pl

command.

HTTP Header Field

Use this table to specify custom, non-standard HTTP Request header fields that you want to pass to your CGI applications. If a request contains a header line with the specified field name, the line is passed to CGI applications as an environment variable with the HTTP_H_convertedFieldName name, where convertedFieldName is the field name in the uppercase letters, with all minus (-) symbols substituted with the underscore (_) symbols.

CGI programs can be used to extend functionality of the WebUser Interface. They can log into the Server via its PWD module to do some CLI/API operations and/or via the IMAP module to access and modify mailbox data. To simplify these login operations, CGI programs can use the WebUser Authenitcation method.