Chapter 10: Advanced Features

Configuring a Custom Suffix Mapping

On startup, WEB·FM automatically defines a web server suffix mapping entry for ".fm". Any HTTP request for a file ending in ".fm" will automatically be mapping to the WEB·FM action for processing, which is also automatically defined on startup.

It may be useful to manually enter and use a web server suffix entry other than ".fm". Perhaps the names of your databases have a different suffix (".fp3" for example), or you might prefer a suffix which better markets your online presence (".orders" for example). To do this, simply define a new web server suffix entry mapped to the WEB·FM action. If the name of the target database does not actually have the suffix used, WEB·FM will automatically strip the suffix from the file request.

Using HTTP Request Parameters

WEB·FM provides a way to temporarily capture to the target database many of the client HTTP request parameters received by the web server. These parameters may prove useful in some way for scripts or calculation fields which you may have in the database. They are also useful in implementing intelligent server-side include features without having to rely on another web server add-on. There can be a small performance hit by using this feature on older model servers, so if you don't use this feature do not include the "WWW" field in your database.

Create a new Global field in your database named "WWW" and give it 20 repeating cells.

Upon every transaction WEB·FM will place 20 HTTP request parameters into the repeating cells. Using a script or calculation and the GetRepetition() function you can access a specific cell for the desired parameter and take action based upon that parameter. The first cell can normally be referred to by field name alone (WWW) without using the GetRepetition() function since it's the first repetition. The order in which repeating cell values get data is as follows:

1.	FormData	Submitted form data, or search argument portion of URL
2	Method	HTTP method (e.g. GET, POST)
3	Domain	Domain name of client
4	Username	Username for current authentication scheme
5	Password	Password for current authentication scheme
6	Email	"From" header field (email address when supplied)
7	ServerName	Domain name of server
8	ServerPort	Port number of server
9	URLPath	URLPath
10	Command	Database command (or Path argument portion of URL)
11	Referer	Refering document
12	Browser
13	Realm
14	SearchArg
15	ClientIP
16	FullRequest
17
18	TotalConnections
19	CurrentUserLevel
20	HighestUserLevel

As an example for how the "www" field might be used, you can tailor your HTML documents to the specific browser of the client. By retrieving the HTTP data that tells you what browser the client is using, you can send a Retrieve command to your FileMaker Pro database that will deliver the appropriate HTML for each specific browser.

Returning a Custom HTTP Response Header

If the reply document (Template file or HTML field) begins with a raw HTTP header, WEB·FM does NOT prepend an HTTP response header to the out-going HTML. You are responsible for building a valid HTTP response header properly formatted with the appropriate number of returns and line feeds.

Advanced uses might include sending a URL redirect to the client browser for sending an email message using another plug-in, or setting a browser "cookie" value for an online shopping cart complete with expiration dates.

Example:

HTTP/1.0 302 Found
Location: cookie.fm$Add?cookie=[cookie]&html=detail.html
Set-Cookie: CUSTOMER=WILE_E_COYOTE; path=/; expires=Tuesday, 31-Dec-96 23:12:40 GMT

Custom HTTP Header Fields

The Admin database includes a tab (shown below) for specifying custom HTTP response header fields. Entries are appended to the HTTP header WEB·FM sends to the browser in reply to a request. Custom HTTP fields are applied at the database level for every request. This has the advantage of not requiring some tags in every HTML document.

Use a Content-Type field for better international character support in conjunction with the Encoder and Decoder Processors.

Use a Last-Modified field to force the client browser to locally cache database transactions. For example, you might create a small, simple database with the sole purpose of serving Find forms with dynamic population of pop-up menus from a changing database value list. In this way, an index page of some kind could be referred to throughout a web site and not require another database hit after the first request.