Oracle Web Cache Administration and Deployment Guide Release 1.0.2 Part Number A86722-01 |
Library | Service | Contents | Index

# 8
Administering Oracle Web Cache

This chapter explains how to perform administrative tasks to Oracle Web Cache. It contains these topics:

- Starting and Stopping Oracle Web Cache

- Invalidating Documents in the Cache

- Evaluating Event Logs

- Evaluating Access Logs

## Starting and Stopping Oracle Web Cache

Anytime Oracle Web Cache's configuration is modified, Oracle Web Cache must be stopped and restarted. To start and stop Oracle Web Cache, use either Oracle Web Cache Control Manager or the `webcachectl` utility. When you start Oracle Web Cache, the `admin` server process for the administrative interface and the `cache` server process for the actual cache are started.

Use Oracle Web Cache Manager... | Use the webcachectl Utility...
--- | ---
1. Start Oracle Web Cache Manager. See Also: "Starting Oracle Web Cache Manager" In the navigator pane, select Administering Oracle Web Cache > Oracle Web Cache Operations. The Oracle Web Cache Operations page appears in the right pane. In the Oracle Web Cache Operations page, choose Start or Stop. | To start Oracle Web Cache: Determine the status of Oracle Web Cache. From the command line, enter:
       webcachectl status
   If the following message appears, Oracle Web Cache is not running. Continue to Step 2.
       Oracle Web Cache admin server is NOT running.
       Oracle Web Cache cache server is NOT running.
   If the following message appears, Oracle Web Cache is already running.
       Oracle Web Cache admin server is running
       (pid=pid).
       Oracle Web Cache cache server is running
       (pid=pid)
2. Start Oracle Web Cache. From the command line, enter:
       webcachectl start
   The following message appears:
       Oracle Web Cache started
To stop Oracle Web Cache, from the command line, enter:
    webcachectl stop
The following message appears:
    Oracle Web Cache admin server stopping.
    Oracle Web Cache cache server stopping.

On Windows NT, Oracle Web Cache can also be started through the Control Panel:

1. Double-click the Services icon in the Control Panel window.

2. Select the OracleHOME_NAMEWebCacheAdmin service to start the `admin` server.

3. Choose Start to start the service.

4. Select the OracleHOME_NAMEWebCache service to start the `cache` server.

5. In the Services window, choose Close.

## Invalidating Documents in the Cache

Invalidation messages are sent to Oracle Web Cache to an invalidation listening port through HTTP `POST` messages. The invalidation messages identify the documents to be invalidated. This section contains the following invalidation-related topics:

- Setting the Invalidation Port Number

- Sending Invalidation Messages

- Invalidation Examples

### Setting the Invalidation Port Number

By default, Oracle Web Cache listens for invalidation requests at port 4001.

To change the default port number:

1. Start Oracle Web Cache Manager.

   See Also: "Starting Oracle Web Cache Manager"

2. Change the port numbers:

   1. In the navigator pane, select Administering Oracle Web Cache > Invalidation/Statistics Port.

      The Invalidation/Statistics Port page appears in the right pane.

   1. In the Invalidation/Statistics Port page, choose Edit.

      The Change Invalidation/Statistics Port dialog box appears.

   2. In the New Invalidation Port field, enter the new port.

   3. Choose Submit.

3. In the Oracle Web Cache main window, choose Apply Changes.

### Sending Invalidation Messages

You can send invalidation `POST` messages using one of the following methods:

- Using HTTP POST Messages

- Using Oracle Web Cache Manager

- Using Database Triggers

#### Using HTTP POST Messages

When you send an invalidation message with a HTTP `POST` message, you specify the host name of Oracle Web Cache, the invalidation listening port number, and the invalidation message.

For example, if you were using `telnet`, you would send an invalidation message using the following procedure:

1. Connect to Oracle Web Cache at the invalidation listening port:

       telnet webcache_host invalidation_port

2. Once you have telneted to the port, specify a `POST` message header and authenticate the user invalidator using Base64 encoding string with the following syntax.

       POST /x-oracle-cache-invalidation http/1.0|1
       Authorization: BASIC <base64 encryption of invalidator:invalidator_password>
       content-length:#bytes

   An example of `Authorization: BASIC <``base64 encryption of invalidator:invalidator_password``>` follows:

       Authorization: BASIC aW52YWxpZGF0b3I6YWRtaW4=

   In this example, `aW52YWxpZGF0b3I6YWRtaW4=` is "invalidator:admin" encoded.

   See Also: "Task 2: Modify Security Settings" for further information about changing the invalidation password

3. Enter one carriage return.

4. Send the invalidation message with the following Extensible Markup Language (XML) syntax:

       <?xml version="1.0"?>

       <!DOCTYPE INVALIDATION SYSTEM "internal:///invalidation.dtd">
       <INVALIDATION>
           <URL EXP="URL" PREFIX="YES|NO">
               <VALIDITY LEVEL="validity" REFRESHTIME="seconds"/>
               <COOKIE NAME="cookie_name" VALUE="value" NONEXIST="YES|NO"/>
               <HEADER NAME="HTTP_request_header" VALUE="value"/>
           </URL>
       </INVALIDATION>

Table 8-1 Invalidation Message Syntax

#####

Invalidation Element/Attribute | Description
--- | ---
`URL` | Required element in the invalidation message. You can specify more than one URL element in the message.
`EXP` | Required attribute for the `URL` element. Specify the URL of the documents you want to invalidate.
`PREFIX` | Optional attribute for the `URL` element. Specify `YES` to invalidate documents contained within the URL, as well as recursive directories of the URL; specify `NO` to only invalidate documents contained within the URL. `NO` is the default.
`VALIDITY` | Required element in the invalidation message.
`LEVEL` | Optional attribute for the `VALIDITY` element. Specify the validity level for the documents. The validity level ranges from 0 (for the least valid) to 9 (for the most valid). The higher the validity level, the longer Oracle Web Cache will serve these documents stale from the cache before removing them. For documents with lower validity levels, Oracle Web Cache will serve these documents stale for a short amount of time before removing them. After documents are removed, Oracle Web Cache retrieves new versions of the documents from the application Web servers. A validity level of 0 means Oracle Web Cache will remove documents immediately. The default validity level is 0.
`REFRESHTIME` | Optional attribute for the `VALIDITY` element. Specify the maximum time that documents can reside in the cache.
`COOKIE` | Optional element in the invalidation message.
`NAME` | Required attribute for the `COOKIE` element. Specify the cookie name to invalidate documents based on the cookie. The name must match the cookie name of a multiple-version cacheability rule associated with this URL.
`VALUE` | Optional attribute for the `COOKIE` element. Specify the value of the cookie.
`NONEXIST` | Optional attribute for the `COOKIE` element. Specify `YES` to invalidate documents for requests without this cookie; specify `NO` to invalidate documents for requests with this cookie. `NO` is the default.
`HEADER` | Optional element in the invalidation message.
`NAME` | Required attribute for the `HEADER` element. Specify the HTTP request header

and its value to invalidate based on the request header. The name must match the header of a multiple-version cacheability rule associated with this URL.

`VALUE`

Optional attribute for the `HEADER` element.

Specify the value of the header.

See Also: "Invalidation Request DTD" for further information about invalidation request syntax

Invalidation responses are returned in the following format:

    <?xml version="1.0"?>
    <!DOCTYPE INVALIDATIONRESULT [
    <!ELEMENT INVALIDATIONRESULT (URL+)>
    <!ELEMENT URL   EMPTY>
    <!ATTLIST URL
              EXPR          CDATA   #REQUIRED
              ID            CDATA   #REQUIRED
              STATUS        CDATA   #REQUIRED
              NUMINV        CDATA   #REQUIRED
    >
    ]>
    <INVALIDATIONRESULT>
    <URL EXPR="URL" ID="ID" STATUS="status" NUMINV="number">
    </INVALIDATIONRESULT>

Table 8-2 Invalidation Response Syntax

#####

Invalidation Element/Attribute | Description
--- | ---
`URL` |
`EXP` | Specifies the URLs of the documents that you requested to be invalidated
`ID` | Sequence number of all the URLs sent in the invalidation response. If there are multiple URLs specified in the invalidation message, then the sequence number starts at 1 for the first URL and sequentially numbers for each additional URL.
`STATUS` | Status of the invalidation. Status can be one of the following: `SUCCESS` for successful invalidations `URI NOT CACHEABLE` for documents not in the cache `URI NOT FOUND` for documents not found
`NUMINV` | Number of documents invalidated

See Also: "Invalidation Response DTD" for further information about invalidation response syntax

#### Using Oracle Web Cache Manager

You can use Oracle Web Cache Manager to invalidate documents in the cache.

To invalidate documents with Oracle Web Cache Manager:

1. Start Oracle Web Cache Manager.

   See Also: "Starting Oracle Web Cache Manager"

2. In the navigator pane, select Administering Oracle Web Cache > Cache Cleanup.

   The Cache Cleanup page appears in the right pane.

3. In the URL Scope section, specify which documents you want to invalidate:

   ALL | Select to remove all documents from the cache.
   URL or URL Prefix | Select to remove documents contained within a specific URL or URL prefix.
   Include Subdirectories | Select to include subdirectories of the URL prefix entered. For example, if a development group added new scripts to the `/cgi-bin/` directory on the application Web servers, then all the scripts in `../cgi-bin/` would need to be invalidated.

4. In the Action section, specify how you want Oracle Web Cache to process invalid documents.

   Remove immediately | Select this option to have Oracle Web Cache mark documents as invalid and then refresh them immediately with new content from the application Web servers. This is equivalent to a validity level of 0.
   Refresh on demand as application Web server capacity permits AND no later than <time> after submission | Select this option to have Oracle Web Cache mark documents as invalid and then refresh them based on application Web server capacity. Enter the maximum time in which the documents can reside in the cache. Optionally, select a validity level for the documents after they expire. Validity determines how long Oracle Web Cache will serve documents stale from the cache before marking them as invalid. The validity level ranges from 1 (for the least valid) to 9 (for the most valid). The higher the validity level, the longer Oracle Web Cache will serve these documents stale from the cache before marking them as invalid. For documents with lower validity levels, Oracle Web Cache will serve these documents stale for a short amount of time before marking them as invalid.

   Note: Performance assurance heuristics apply when you configure documents to be refreshed based on when the application Web servers can refresh them; performance assurance heuristics do not apply when documents are immediately removed.

5. Choose Submit.

#### Using Database Triggers

Database triggers are procedures that are stored in the database and activated ("fired") when specific conditions occur, such as adding a row to a table. You can use triggers to send invalidation messages. To this do, use the `UTL_TCP` Oracle supplied package to send invalidation messages through database triggers.

See Also: `README.examples` in the `$ORACLE_HOME/webcache/examples` directory on UNIX and`ORACLE_HOME``\webcache\examples` directory on Windows NT for further information about using the `cre_invalid_trig.sql` script to create a database trigger and the `utl_proc.sql` script to demonstrate invalidation with database triggers PL/SQL User's Guide and Reference

### Invalidation Examples

These examples require utilizing the `POST` method which also requires sending the number of bytes (or characters) in the `content_length:` `#bytes` portion of the header. Please note that one carriage return is required after the `content_length:` `#bytes` line and before the XML message or `BODY` information.

#### Example: Invalidating One Document

Invalidation message:

    <?xml version="1.0" ?>

    <!DOCTYPE INVALIDATION SYSTEM "internal:///invalidation.dtd">
    <INVALIDATION>
        <URL EXP="/images/logo.gif" PREFIX="NO">
            <VALIDITY LEVEL="1"/>
        </URL>
    </INVALIDATION>

Invalidation response:

    <?xml version="1.0"?>
    <!DOCTYPE INVALIDATIONRESULT [
    <!ELEMENT INVALIDATIONRESULT (URL+)>
    <!ELEMENT URL   EMPTY>
    <!ATTLIST URL
              EXPR          CDATA   #REQUIRED
              ID            CDATA   #REQUIRED
              STATUS        CDATA   #REQUIRED
              NUMINV        CDATA   #REQUIRED
    >
    ]>
    <INVALIDATIONRESULT>
    <URL EXPR="/images/logo.gif" ID="1" STATUS="SUCCESS" NUMINV="1">
    </INVALIDATIONRESULT>

#### Example: Invalidating a Subtree of Documents

Invalidation message:

    <?xml version="1.0"?>

    <!DOCTYPE INVALIDATION SYSTEM "internal:///invalidation.dtd">
    <INVALIDATION>
        <URL EXP="/images/" PREFIX="YES">
            <VALIDITY LEVEL="1" REFRESHTIME="60"/>
        </URL>
    </INVALIDATION>

Invalidation response:

    <?xml version="1.0"?>
    <!DOCTYPE INVALIDATIONRESULT [
    <!ELEMENT INVALIDATIONRESULT (URL+)>
    <!ELEMENT URL   EMPTY>
    <!ATTLIST URL
              EXPR          CDATA   #REQUIRED
              ID            CDATA   #REQUIRED
              STATUS        CDATA   #REQUIRED
              NUMINV        CDATA   #REQUIRED
    >
    ]>
    <INVALIDATIONRESULT>
    <URL EXPR="/images/" ID="1" STATUS="SUCCESS" NUMINV="125">
    </INVALIDATIONRESULT>

#### Example: Invalidating All Documents for a Web Site

Invalidation message:

    <?xml version="1.0"?>

    <!DOCTYPE INVALIDATION SYSTEM "internal:///invalidation.dtd">
    <INVALIDATION>
        <URL EXP="/" PREFIX="YES">
            <VALIDITY LEVEL="0"/>
        </URL>
    </INVALIDATION>

Invalidation response:

    <?xml version="1.0"?>
    <!DOCTYPE INVALIDATIONRESULT [
    <!ELEMENT INVALIDATIONRESULT (URL+)>
    <!ELEMENT URL   EMPTY>
    <!ATTLIST URL
              EXPR          CDATA   #REQUIRED
              ID            CDATA   #REQUIRED
              STATUS        CDATA   #REQUIRED
              NUMINV        CDATA   #REQUIRED
    >
    ]>
    <INVALIDATIONRESULT>
    <URL EXPR="/" ID="1" STATUS="SUCCESS" NUMINV="5347">
    </INVALIDATIONRESULT>

## Evaluating Event Logs

Oracle Web Cache events and errors are stored in an event log. The event log can help you determine what documents or objects have been inserted into the cache. It can also identify listening port conflicts or startup and shutdown issues. The event log has a file name of `error_log` and is stored in `$ORACLE_HOME/webcache/logs` on UNIX and O `RACLE_HOME``/webcache/logs` on Windows NT.

See Also: Appendix D, "Event Log Messages" for descriptions of the most common event log messages

### Format of the Event Log File

Events are formatted into the following fields:

    Timestamp   Information/Warning/Error   Message

### Event Log Examples

#### Example: Event Log with Startup Entries

Figure 8-1 shows an event log excerpt with successful startup entries.

#### Figure 8-1 Event Log with Successful Startup Entries

    19/Sep/2000:10:20:56 -0500 -- Information: Max Connect Count exceeds compile
    time limit - defaulting to
    connect limit: ( 854 )
    19/Sep/2000:10:20:57 -0500 -- Information: Listening on ADMINISTRATION port 5000
    address 0.0.0.0
    19/Sep/2000:10:20:57 -0500 -- Information: The admin server started successfully
    19/Sep/2000:10:20:57 -0500 -- Information: Max Connect Count exceeds compile
    time limit - defaulting to
    connect limit: ( 854 )
    19/Sep/2000:10:20:57 -0500 -- Information: Listening on NORM port 1100 address
    0.0.0.0
    19/Sep/2000:10:20:57 -0500 -- Information: Listening on INVALIDATION port 5001
    address 0.0.0.0
    19/Sep/2000:10:20:57 -0500 -- Information: Listening on STATISTICS port 5002
    address 0.0.0.0
    19/Sep/2000:10:20:58 -0500 -- Information: The cache server started successfully
    19/Sep/2000:10:20:58 -0500 -- Information: The cache server is started by the
    admin server at startup

#### Example: Event Log with Unsuccessful Startup Entries

Figure 8-2 shows an event log excerpt with unsuccessful startup events. Oracle Web Cache is unable to listen on port 1100, because it is already in use. This can occur if Oracle Web Cache is already running and listening on that port or another application is using that port.

#### Figure 8-2 Event Log with an Unsuccessful Startup

    14/Sep/2000:16:37:41 -0800 -- Error: A failure occurred ( Address already in use
    ) when assigning a port ( domain: <NONE>, address: 0.0.0.0, port: 1100 ). Change
    PORT attribute of the LISTEN element in the configuration file to a suitable
    unused port.
    14/Sep/2000:16:37:41 -0800 -- Error: Failed to start the server.
    14/Sep/2000:16:37:41 -0800 -- Error: The server could not initialize
    14/Sep/2000:16:37:41 -0800 -- Information: The server is exiting

#### Example: Event Log with an Invalidation Entry

Figure 8-3 shows an event log excerpt with an event associated with an invalidation request for the removal of document `personal.htm`.

#### Figure 8-3 Event Log with an Invalidation Entry

    30/Sep/2000:22:52:52 -0500 -- Information: <Invalidation>1 URLs with prefix
    personal.htm have been successfully invalidated.

#### Example: Event Log with an Invalidation Message Error

Figure 8-4 shows an event log excerpt with an XML invalidation message error. In this example, Oracle Web Cache is unable to parse the message.

#### Figure 8-4 Event Log with an Invalidation Message Error

    Example: Errors in the XML parsing. Note: The configuration files and
    invalidation files use XML
    files.
    19/Sep/2000:10:55:26 -0500 -- Error: Invalidation XML Buffer cannot be parsed.
    19/Sep/2000:10:55:26 -0500 -- Error: XML parsing error.

#### Example: Event Log with Shutdown Entries

Figure 8-5 shows an event log excerpt with typical shutdown entries.

#### Figure 8-5 Event Log with Shutdown Entries

    14/Sep/2000:11:16:55 -0700 -- Information: SIGTERM caught - program will shut
    down once all connections are complete.
    14/Sep/2000:11:16:55 -0800 -- Information: SIGTERM caught - program will shut
    down once all connections are complete.
    14/Sep/2000:11:16:55 -0700 -- Information: The server is exiting
    14/Sep/2000:11:16:55 -0800 -- Information: The server is exiting

### Finding Errors in the Event Log

To list just the errors in the event log, use `grep` on UNIX. For example:

    grep  " Error:" error*

To list the errors by the current day, enter `grep " Error:" error_log "dd/mon/yyyy"`. For example:

    grep  " Error:" error_log | grep "19/Sep/2000"

To list errors by the current day and hour, enter `grep " Error:" error_log "dd/mon/yyyy:hh"`.

### Configuring Event Logs

To configure event log configuration settings:

1. Start Oracle Web Cache Manager.

   See Also: "Starting Oracle Web Cache Manager"

2. In the navigator pane, select Administering Oracle Web Cache > Event Logging.

   The Event Logging page appears in the right pane.

3. In the Event Logging page, choose Edit

   The Change Options for Event Logs dialog box appears.

4. In Logging Time Format, select either Local or Greenwich Mean Time to modify the time stamp style associated with entries in the event log file.

5. In Verbose Logging, select either No to log typical events or Yes to log typical events, plus application Web server events. Verbose event logs are used for debugging purposes. Therefore, select Yes if recommended by Oracle Support Services.

6. Choose Submit.

7. In the Oracle Web Cache main window, choose Apply Changes.

## Evaluating Access Logs

Each Web site that Oracle Web Cache supports has its own access log. An access log contains information about the HTTP requests sent to Oracle Web Cache for a Web site. The access log has a file name of `access_log` and is stored by default in `$ORACLE_HOME/webcache/logs` on UNIX and O `RACLE_HOME``/webcache/logs` on Windows NT. Note that Oracle Web Cache uses buffered logging for the access log, that is, it writes to the access log after the buffer is full.

### Format of the Access Log File

You can configure the content of the access log file by defining the fields to appear for each HTTP request event. These fields are a part of the Extended LogFile Format (XLF), which is a superset of the Common LogFile Format (CLF).

Table 8-3 lists the XLF fields you can select.

##### Table 8-3 XLF Fields for Access Logs

Field | Description
--- | ---
`cs(User-Agent)` | Information about the user agent originating the request
`cs(Referer)` | Allows the client to specify the address (URI) of the resource from which the Request-URI was obtained
`c-auth-id` | Username if the request contained an attempt to authenticate
`bytes` | Content-length of the transferred document
`date` | Date at which the transaction completed
`time` | Time at which the transaction completed
`time-taken` | Amount of time taken (in seconds) for transaction to complete
`c-ip` | Client's IP address and port
`s-ip` | Oracle Web Cache's IP address and port
`sc-method` | Oracle Web Cache-to-client HTTP request method (`GET`, `POST`, or others)
`sc-status` | Oracle Web Cache-to-client HTTP status code: 1xx range messages are informational. 2xx range messages indicate success. 3xx range messages indicate redirection, indicating that further action must be taken in order to complete the request. 4xx range messages indicate a client error. 5xx range messages indicate a Oracle Web Cache error. See Also: `http://www.ietf.org/rfc/rfc2616.txt` for further information about HTTP status codes
`cs-uri` | Client-to-Oracle Web Cache URI
`cs-uri_stem` | Client-to-Oracle Web Cache stem portion of URI, omitting the query
`cs-uri-query` | Client-to-Oracle Web Cache query portion of URI, omitting the stem
`prefix``(``header``)` | `header` is a HTTP header field and `prefix` is one of the following: `c`: Client `s`: Oracle Web Cache `r`: Remote `cs`: Client-to-Oracle Web Cache `sc`: Oracle Web Cache-to-client

If no fields are specified, then the following default CLF fields are used in the access log file:

`c-ip cauth-id [clf-date] "request line" sc-status bytes`

### Access Log Examples

Figure 8-6 shows an example access log using the default CLF fields:

`c-ip cauth-id [clf-date] "request line" sc-status bytes`

The `"request line"` is represented by the `"GET ...HTTP/1.0"` portion of the request. The `"request line"` enables you to determine what is being accessed and the following `sc_status`, or HTTP status code, reports if the request was successfully completed.

#### Figure 8-6 Access Log

    138.2.213.146 - - [19/Sep/2000:10:27:42 -0500] "GET /~ssandrew/personal.htm
    HTTP/1.0" 200 2438
    138.2.213.146 - - [19/Sep/2000:10:27:54 -0500] "GET
    /~ssandrew/personal.htm?UserName=Bob HTTP/1.0"
    200 2438
    138.2.213.146 - - [19/Sep/2000:10:47:30 -0500] "GET /~ssandrew/count.sh
    HTTP/1.0" 403 289
    138.2.213.146 - - [19/Sep/2000:10:47:34 -0500] "GET /~ssandrew/sbin/count.sh
    HTTP/1.0" 200 321
    138.2.213.146 - - [19/Sep/2000:10:47:41 -0500] "GET /sbin/count.sh HTTP/1.0" 200
    321
    138.2.213.146 - - [19/Sep/2000:11:34:23 -0500] "GET /cache.htm HTTP/1.0" 200 250
    138.2.213.146 - - [19/Sep/2000:11:38:23 -0500] "GET /cache.htm HTTP/1.0" 304 0
    138.2.213.146 - - [19/Sep/2000:11:38:48 -0500] "GET /cache.htm HTTP/1.0" 304 0
    206.223.27.37 - - [19/Sep/2000:15:14:29 -0500] "GET
    /~ssandrew/personal.htm?UserName=Joe HTTP/1.0"
    200 2438
    206.223.27.37 - - [19/Sep/2000:15:17:12 -0500] "GET
    /~ssandrew/personal.htm?UserName=Shehzaad
     HTTP/1.0" 200 438
    144.25.223.39 - - [19/Sep/2000:15:30:34 -0500] "GET /htdocs/coelist.html
    HTTP/1.0" 200 4219
    144.25.223.39 - - [19/Sep/2000:15:30:34 -0500] "GET /images/redheaderbanner.gif
    HTTP/1.0" 200 1226
    138.2.213.146 - - [19/Sep/2000:10:49:44 -0500] "GET /pls/coe/find_via_post
    HTTP/1.0" 200 1119
    138.2.213.146 - - [19/Sep/2000:10:49:44 -0500] "GET /ows-img/chalk.jpg HTTP/1.0"
    404 284
    130.35.35.21 - - [20/Sep/2000:00:36:35 -0500] "GET /images/support.jpg HTTP/1.0"
    206 3106
    130.35.35.21 - - [20/Sep/2000:00:36:35 -0500] "GET /images/ani_coe.gif HTTP/1.0"
    206 73118

#### Example: Access Log with Reload Entries

Figure 8-7 shows an access log excerpt in which there are two Web browser reloads, followed by two shift reloads, and two more reloads.

#### Figure 8-7 Access Log with Reload Entries

    138.2.213.146 - - [19/Sep/2000:11:04:24 -0500] "GET /cache.htm HTTP/1.0" 200 250
    138.2.213.146 - - [19/Sep/2000:11:04:26 -0500] "GET /cache.htm HTTP/1.0" 200 250
    138.2.213.146 - - [19/Sep/2000:11:29:24 -0500] "GET /cache.htm HTTP/1.0" 304 0
    138.2.213.146 - - [19/Sep/2000:11:29:25 -0500] "GET /cache.htm HTTP/1.0" 304 0
    138.2.213.146 - - [19/Sep/2000:11:29:30 -0500] "GET /cache.htm HTTP/1.0" 200 250
    138.2.213.146 - - [19/Sep/2000:11:29:35 -0500] "GET /cache.htm HTTP/1.0" 200 250

#### Example: Access Log with Wrong Path Entry

Figure 8-8 shows an access log excerpt in which a browser requested the wrong path. This is indicated by HTTP status code 403. The browser then requested the correct path. This is indicated by HTTP status code 200.

#### Figure 8-8 Access Log with Wrong Path Entry

    38.2.213.146 - - [19/Sep/2000:10:47:30 -0500] "GET /~ssandrew/count.sh HTTP/1.0"
    403 289
    138.2.213.146 - - [19/Sep/2000:10:47:34 -0500] "GET /~ssandrew/sbin/count.sh
    HTTP/1.0" 200 321

#### Example: Access Log with Status Code 404 Entry

Figure 8-9 shows an access log excerpt in which a Oracle Web Cache cannot find any objects matching the requested URL `/ows-img/chalk.jpg`. This indicated by HTTP status code 404.

#### Figure 8-9 Access Log with HTTP Status Code 404 Entry

    138.2.213.146 - - [19/Sep/2000:10:49:44 -0500] "GET /pls/coe/find_via_post
    HTTP/1.0" 200 1119
    138.2.213.146 - - [19/Sep/2000:10:49:44 -0500] "GET /ows-img/chalk.jpg HTTP/1.0"
    404 284

#### Example: Access Log with Status Code 304 Entry

Figure 8-10 shows an access log excerpt in which the first entry shows a Web browser request for `/cache.htm` being successfully completed. The second and third entries return a HTTP status code of 304, indicating that document has not been modified and does not need to be returned again.

#### Figure 8-10 Access Log with HTTP Status Code 304 Entry

    138.2.213.146 - - [19/Sep/2000:11:34:23 -0500] "GET /cache.htm HTTP/1.0" 200 250
    138.2.213.146 - - [19/Sep/2000:11:38:23 -0500] "GET /cache.htm HTTP/1.0" 304 0
    138.2.213.146 - - [19/Sep/2000:11:38:48 -0500] "GET /cache.htm HTTP/1.0" 304 0

### Configuring Access Logs

To configure access log configuration settings:

1. Start Oracle Web Cache Manager.

   See Also: "Starting Oracle Web Cache Manager"

2. In the navigator pane, select Administering Web Sites > Access Logging.

   The Access Logs page appears in the right pane.

3. In the Access Logs page, choose Edit

   The Change Options for Access Logs dialog box appears.

4. In Logging Enabled, select YES.

5. In the Logging Directory field, enter the directory path where you want the log file written.

6. In Logging Time Format, select either Local or Greenwich Mean Time to modify the time stamp style associated with entries in the access log file.

7. From the Rollover Frequency list, select how often you want to change the frequency at which the access log file is overwritten. If you have a high-volume site, increase the frequency.

8. In the XLF Fields field, enter XLF fields to log. Separate fields by a space.

9. Choose Submit.

10. In the Oracle Web Cache main window, choose Apply Changes.

| Copyright © 1996-2000 Oracle Corporation. All Rights Reserved. |
Library | Service | Contents | Index