WebSTAR 4 Manual & Technical Reference

Manual Contents | Chapter Contents | Previous Page | Next Page

---

Web Serving and HTTP

This section describes how WebSTAR handles HTTP connections, including techniques for tracking user interaction; realm and web user security processing of URLs; procedure for serving a requested file or other data; and how WebSTAR responds to errors.

HTTP Connections

The HyperText Transfer Protocol (HTTP) defines how a Web server handles connections. Unlike some protocols, HTTP opens connections only for as long as needed to transfer the requested data. The connections are then closed immediately. Even "persistent" connections do not create a long-term link between the server and the client: as soon as the data is transferred, the connection is closed.

The WebSTAR Web server also supports the HTTPS (secure) protocol. It works like HTTP, but the data is encrypted before being transmitted. For more information, see SSL Web Security .

This method of handling connections has a few implications for the administrator of a Web server. First, there is no way for WebSTAR to keep track of where a connection leads. So, if a browser requests data from your server, there is no way for the WebSTAR Web server to track which links are followed within that data, because the connection is closed once the original data is returned.

Per-File Connections

In addition, each separate element in a page requires its own connection. For example, a page of text requires one connection to download. If that page contains a graphic, another connection is required. Therefore, connection information is not necessarily a reliable way of analyzing a server's activity. For example, if you have a server with 5,000 connections a day serving a text document and you add a graphic to that document, your server will suddenly report serving 10,000 connections a day, simply because it's serving an additional graphic each time.

By using the Persistent Connections feature of WebSTAR, the server can hold open a single connection and use it to transmit multiple files, thus reducing the overhead of setting up and closing connections.

see Use DNS for Server and Client Lookups .

Creating Client "Sessions"

As described above, HTTP closes connections as soon as the requested data is served. However, there are many good reasons why you would want to keep track of a person as they go through your site, and after they leave and come back. For example, you may want to suggest related pages, track online tests, show them what's new since the last time they looked at the site, or track the choices on a store.

There are a number of approaches to tracking viewers to your site:

• cookies are a standard solution. Most browsers can store these small amounts of information, which is sent back to the server when the browser accesses the site again. For more information, see:

 
http://search.netscape.com/assist/security/faqs/cookies.html

• WebObjects is Apple's high-end middleware solution that tracks browser interaction with the server and connects to large databases, and other WebObjects systems. For more information, see WebSTAR WebObjects Adaptor , and

 
http://software.apple.com/webobjects/

• Database modules can track by host name and IP number, allowing you to control what the visitor sees by where they have been before.
• eCommerce modules can include a "shopping basket" function, so shoppers can store their choices for later purchase. For more information, see:

 
http://www.starnine.com/extendingwebstar.html

Analyzing User Interaction

You can also track people viewing your site by viewing your log files (see Web Server Logging ). For statistics and analysis, you may want to use a log analyzer. Many of them will let you learn how people travel within your site and which elements are the most effective. Many log analysis programs are available: see the Extending WebSTAR pages for links.

WebSTAR URL Processing

The Web browser (client) software is responsible for constructing the full URL for a document, which contains the server's hostname and possibly a path to the folder or file containing the desired data.

Once the WebSTAR Web server receives the URL and has routed it to the correct host, it has to find the data. Some URLs are for files, others for CGIs and Plug-Ins, but the process is very much the same.

For example, this is a full URL to an HTML document:

http://www.domain.com/widgets/bluewidget.html

The client machine looks up the domain in the DNS registry, and locates the IP address of your WebSTAR server machine.

Starting at the Root

By default, WebSTAR analyzes URLs relative to its own position on the disk. Therefore, the WebSTAR root folder for the WebSTAR web server is the folder in which the server application resides. A root URL is just the name of your host, which will bring up your default or index file in the root folder:

http://www.domain.com

If you are serving several hosts, the root folder for each of those hosts is the folder that you designate in the Virtual Hosts list. WebSTAR will respond to the URL relative to that folder for that virtual host, so it will bring up the index or default file in that folder.

For more information on virtual hosts, see below and Routing to Virtual Hosts .

How WebSTAR Handles a URL

When the WebSTAR server receives an incoming URL, it performs the steps described below.

• If you are using virtual hosts, it routes the URL to the correct site, depending on the IP address, domain name, and/or language (see Routing to Virtual Hosts ). Otherwise, this step is skipped.
• If you have any Filter Plug-Ins installed, they perform their filter task on the request.
• If a Pre-Processor is installed, it will run next (see Pre-Processor ).
• WebSTAR will also check for security controls on your server., as described in WebSTAR URL Security Processing .

See Security Realms .

From here on, the WebSTAR web server works on the data path elements of the URL. In this example:

 
http://www.domain.com/widgets/bluewidget.html

the data path elements are

widgets/bluewidget.html

The processing steps are:

1 WebSTAR converts the slashes in the URL to colons to obtain a Macintosh file path. In this case, it's "widgets:bluewidget.html".

2 The web server then converts any HTTP special characters from the two-digit hex numbers (such as " %20 " for space) to Mac characters. For more information, see Macintosh Special Characters in File Names .

It also replaces double colons ( :: ) with a single colon (:) to prevent clients from accessing parent directories in the Mac OS file system.

3 If the URL is for a folder (because it ends with a trailing slash), WebSTAR will automatically get the index file.

• If there is a .message file in the folder and the Directory Index Plug-In is installed), the server will call the Plug-In to display a list of the files in that folder, and will skip the rest of the steps in this section.
• Otherwise, it will serve the default file for that folder (as specified by the default index file setting, such as default.html ). It will continue to the next step, using that file for future processing.

4 WebSTAR then looks up the file requested by the URL in the Suffix Mapping Table, using the file suffix or File Type and Creator (see How Suffix Mapping Works ).

If the URL points to an alias, WebSTAR will use the suffix of the alias: it will not use the suffix of the original file.

5 If the file is a redirect file or other RAW file, WebSTAR returns it without adding any header information (see Redirect Files ).

6 If the Action is Binary, or Text, the WebSTAR web server returns the contents of the requested file to the browser, without changing it in any way. If it's already in the Data Cache, the server can send it very quickly, without reading the file from the disk.

7 If the Suffix Mapping Action refers to a CGI or Plug-In, WebSTAR calls that module and sends it the URL. The CGI or Plug-In uses the URL define the requested task: in most cases it will retrieve information, process the data and send the HTML page or data to WebSTAR, which will send it back to the client without any additional changes.

For more information, see Suffix Mapping .

8 If no file is found, the URL matches a path to a folder, and it does not have the trailing slash, WebSTAR will return a redirect URL for that folder with the trailing slash, so the browser can resubmit the entry automatically for the index file. For example, this URL:

 
http://www.domain.com/widgets

will be converted to:

 
http://www.domain.com/widgets/

9 If none of these conditions are met, the request is an error. WebSTAR will return an error message for the host, as described in the next section.

Responding To Errors

If the requested data was not found, or the person requesting it was denied access to a security realm, WebSTAR will return one of the specified error messages.

To designate a special error file or use a third-party CGI or Plug-In to respond to these errors, redirecting the browser to another file or giving a more useful error message, see Default Names .

If you are using Virtual Hosting, each host can have separate error message settings. See Virtual Host Options .

Error.html: "File Not Found" Error Message

If a browser sends a URL for a file that does not exist, WebSTAR will send back a standard error message. The default behavior is to send the file Error.html , installed in the root folder, which has a "File Not Found" error message.

You can edit that file in your favorite HTML editor, to make it more useful to people accessing your site. For example, you can add a site map, a list of the most important links on your site, or a search form for your site--all tools to make it easier for your visitors to get back on track. You should also add the webmaster email address and consider providing a contact phone number as well.

Noaccess.html: "Access Denied" Error Message

You can use the Global option in the Allow/Deny interface to deny a browser access to the entire host, according to the browser machine's host name, domain name or IP address. If you do so, and a browser from that domain attempts to access the server, they will get the No Access error page.

The default behavior is to send the file NoAccess.html from the root folder, with an "Access Denied" message. You can edit that file in your favorite HTML editor to explain how they can get access to the host, or replace the file entirely.

"Not Authorized" Error Message

When a browser tries to access a secure realm, but the user does not enter a valid user name and password, the web server will return the pre-set Not Authorized error message. You cannot edit this message in HTML.

WebSTAR URL Security Processing

When WebSTAR gets a URL, it must first make sure that the browser machine is allowed to access that particular data. Only once it has checked all security options will it go on to find and serve the data, as described below in WebSTAR URL Processing .

1 First, the WebSTAR server will check the global Allow/Deny settings for a match.

For information on using this security, see Allow/Deny .

If there are global Allow/Deny settings, and this host name or IP address is not granted access, WebSTAR rejects the request and returns the No Access response.

2 Otherwise, WebSTAR checks the Realms list for a match between the any part of the requested URL and the match strings.

If there is no match, skip to step Call all security Plug-Ins. These third-party modules provide different forms of security and access control. Even if you do not use Realms, they will get a chance to perform security and access checking. .

3 WebSTAR checks to see if the browser has passed an authenticated username and password for this session (which means that a user has entered a correct user name and password from this host already).

If it has already been authenticated, it will not require the login for every secure page, so WebSTAR will skip to step Call all security Plug-Ins. These third-party modules provide different forms of security and access control. Even if you do not use Realms, they will get a chance to perform security and access checking. .

4 Otherwise, check if there is an Allow or Deny entry for the realm.

If there is an Allow entry for the realm, skip to step Call all security Plug-Ins. These third-party modules provide different forms of security and access control. Even if you do not use Realms, they will get a chance to perform security and access checking. .

5 If there is no Allow entry, or there is a Deny entry, respond to the browser requesting a User Name and Password.

After a denial, the User Name and Password dialog will always appear in the browser, even if there is no User entry associated with a realm.

• If they enter a correct User Name and Password, send that authentication information back to the browser, for future reference (it's used in step WebSTAR checks to see if the browser has passed an authenticated username and password for this session (which means that a user has entered a correct user name and password from this host already). ).
• If the user cannot enter the correct User Name and Password, reject the request and display the "Not Authorized" page.
6 Call all security Plug-Ins. These third-party modules provide different forms of security and access control. Even if you do not use Realms, they will get a chance to perform security and access checking.
7 If all security Plug-Ins approve the request, the WebSTAR web server returns the file or data requested by the URL.

WebSTAR Security URL Processing

Manual Contents | Chapter Contents | Previous Page | Next Page