Oracle9iAS Web Cache Administration and Deployment Guide Release 2.0.0 Part Number A90372-04 |
|
This chapter explains how to perform administrative tasks to Oracle Web Cache.
This chapter contains these topics:
Anytime Oracle Web Cache's configuration is modified, you must stop and restart Oracle Web Cache. To start, stop, or restart Oracle Web Cache, use either Oracle Web Cache Manager or the webcachectl
utility.
When you stop Oracle Web Cache, all objects are cleared from the cache. In addition, all statistics are cleared.
When you start Oracle Web Cache from the webcachectl
utility, the admin server process for the administrative interface and the cache server process for the actual cache are started. Oracle Web Cache Manager starts only the
cache
server process. To initialize Oracle Web Cache for the first time, use the webcachectl
utility to start both processes.
Use Oracle Web Cache Manager... | Use the webcachectl Utility... |
---|---|
To start the
|
To start Oracle Web Cache:
To stop Oracle Web Cache, from the command line, enter:
The following message appears:
|
On Windows, Oracle Web Cache can also be started through the Control Panel:
The Services window appears.
Oracle
HOME_NAMEWebCacheAdmin
service to start the admin
server, and then choose Start to start the service.
Oracle
HOME_NAMEWebCache
service to start the cache
server, and then choose Start to start the service.
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:
By default, Oracle Web Cache listens for invalidation requests at port 4001 on HTTP.
To change the default port number or protocol:
The Oracle Web Cache Invalidation/Statistics Port page appears in the right pane.
The Change Invalidation/Statistics Port dialog box appears.
http://web_cache_hostname
:http_port
https://web_cache_hostname
:https_port
Invalidation messages are HTTP POST
messages written in Extensible Markup Language (XML) syntax. The contents of the XML message body tell the cache which URLs to mark as invalid. As shown in Figure 8-1, invalidation messages can be sent using one of the following methods:
telnet
This section describes how to send invalidation messages using one of the following methods:
When you send an invalidation message with an 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:
telnet web_cache_host invalidation_port
POST
message header and authenticate the user invalidator
using Base64 encoding string with the following syntax.
POST /x-oracle-cache-invalidate http/1.0|1 Authorization: BASIC <base64 encoding of invalidator:invalidator_password
> content-length:#bytes
An example of Authorization: BASIC <
base64 encoding of invalidator:invalidator_password
>
follows:
Authorization: BASIC aW52YWxpZGF0b3I6YWRtaW4=
In this example, aW52YWxpZGF0b3I6YWRtaW4=
is "invalidator:admin
" encoded.
See Also:
|
Use the following syntax to invalidate document(s) contained within an exact URL that includes the complete path and file name:
<?xml version="1.0" ?> <!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd"> <INVALIDATION VERSION="WCS-1.0"> <OBJECT> <BASICSELECTOR URI="URL"/> <ACTION REMOVALTTL="TTL"/> </OBJECT> </INVALIDATION>
Use the following syntax to invalidate document(s) based on more advanced invalidation selectors:
<?xml version="1.0" ?> <!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd"> <INVALIDATION VERSION="WCS-1.0"> <OBJECT> <ADVANCEDSELECTOR URIPREFIX="prefix" URIEXP="URL_expression"> METHOD="HTTP_request_method"> <COOKIE NAME="cookie_name" VALUE="value"/> <HEADER NAME="HTTP_request_header" VALUE="value"/> </ADVANCEDSELECTOR> <ACTION REMOVALTTL="TTL"/> </OBJECT> </INVALIDATION>
Table 8-1 describes the invalidation message elements and attributes.
Table 8-1 Invalidation Message Syntax
Invalidation responses are returned in the following format for BASICSELECTOR
invalidation messages:
<?xml version="1.0"?> <!DOCTYPE INVALIDATIONRESULT SYSTEM "internal:///WCSinvalidation.dtd"> <INVALIDATIONRESULT VERSION="WCS-1.0"> <OBJECTRESULT> <BASICSELECTOR URI="URL"> </BASICSELECTOR> <RESULT ID="ID" STATUS="status" NUMINV="number"/> </OBJECTRESULT> </INVALIDATIONRESULT>
Invalidation responses are returned in the following format for ADVANCEDSELECTOR
invalidation messages:
<?xml version="1.0"?> <!DOCTYPE INVALIDATIONRESULT SYSTEM "internal:///WCSinvalidation.dtd"> <INVALIDATIONRESULT VERSION="WCS-1.0"> <OBJECTRESULT> <ADVANCEDSELECTOR URIPREFIX="prefix" URIEXP="URL_expression"> METHOD="HTTP_request_method"> <COOKIE NAME="cookie_name" VALUE="value"/> <HEADER NAME="HTTP_request_header" VALUE="value"/> </ADVANCEDSELECTOR> <RESULT ID="ID" STATUS="status" NUMINV="number"/> </OBJECTRESULT> </INVALIDATIONRESULT>
Table 8-2 describes the invalidation response syntax. Note that BASICSELECTOR
and ADVANCEDSELECTOR
are described in Table 8-1.
Oracle Web Cache Manager provides an easy-to-use interface for invalidating cached objects. The message mechanics are much like the telnet
example. The advantage of using Oracle Web Cache Manager is that the administrator is isolated from the intricacies of the HTTP and XML formats, and consequently, there is less chance for error. The administrator need only specify which objects to invalidate and how invalid those objects should be
To invalidate documents with Oracle Web Cache Manager:
The Cache Cleanup page appears in the right pane.
Oracle Web Cache processes the invalidation request, and returns a Cache Cleanup dialog box the shows the invalidation status and the number of objects invalidated. For example:
For prefix-based invalidations that require Oracle Web Cache to traverse a complex directory structure, invalidation can take some time. Therefore, do not choose Submit again until the Cache Cleanup Result dialog box appears. Creating a queue of invalidation requests can degrade the performance of Oracle Web Cache.
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 do this, use the UTL_TCP
Oracle supplied package to send invalidation messages through database triggers.
Many Web sites use scripts for uploading new content to databases and file systems. A large online book retailer, for instance, might run a PERL script once a day in order to bulk load new book listings and price changes into its catalog database. The retailer would want the price changes and availability listings to be reflected in the item views and search results currently cached in Oracle Web Cache. To achieve this, the PERL script can be modified such that when the bulk loading operation has completed, the script will send an invalidation message to the cache invalidating all catalog views and search results. (Note that the invalidation message need not list every individual search page or item view that might be effected by the data change.) The performance assurance feature of Oracle Web Cache enables administrators to use broad brush strokes when invalidating content, making it safe to invalidate all catalog content even if only a fraction of that content has changed.
Invalidation messages can also originate from a Web site's underlying application logic or from the content management application used to design Web pages. Oracle Web Cache ships with invalidation Java or C source that you can link with your applications for generating invalidation messages.
This section contains the following invalidation message examples:
The examples in this section 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.
The following message invalidate file /images/logo.gif
:
<?xml version="1.0" ?> <!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd"> <INVALIDATION VERSION="WCS-1.0"> <OBJECT> <BASICSELECTOR URI="/images/logo.gif"/> <ACTION/> </OBJECT> </INVALIDATION>
Invalidation response:
<?xml version="1.0"?> <!DOCTYPE INVALIDATIONRESULT SYSTEM "internal:///WCSinvalidation.dtd"> <INVALIDATIONRESULT VERSION="WCS-1.0"> <OBJECTRESULT> <BASICSELECTOR URI="/images/logo.gif"/> <RESULT ID="1" STATUS="SUCCESS" NUMINV="1"/> </OBJECTRESULT> </INVALIDATIONRESULT>
The following message invalidates a document exactly matching /contacts/contacts.html
using the BASICSELECTOR
element:
<?xml version="1.0" ?> <!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd"> <INVALIDATION VERSION="WCS-1.0"> <OBJECT> <BASICSELECTOR URI="/contacts/contacts.html"/> <ACTION REMOVALTTL="0"/> </OBJECT> </INVALIDATION>
This is equivalent to the following using the ADVANCEDSELECTOR
element:
<?xml version="1.0" ?> <!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd"> <INVALIDATION VERSION="WCS-1.0"> <OBJECT> <ADVANCEDSELECTOR URIPREFIX="/contacts/" URIEXP="^/contacts/contacts\.html$"/> <ACTION REMOVALTTL="0"/> </OBJECT> </INVALIDATION>
The ADVANCEDSELECTOR
element uses the URIPREFIX
attribute. This attribute is used to traverse the directory structure. The quicker invalidation reaches the right tree level, the quicker the invalidation process is done. The message with the BASICSELECTOR
element is the more efficient of the two examples because there is no directory structure traversal involved.
The following message invalidates two different objects, summary.jsp
and summary.gif
:
<?xml version="1.0" ?> <!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd"> <INVALIDATION VERSION="WCS-1.0"> <OBJECT> <ADVANCEDSELECTOR URIPREFIX="/global/sales/" URIEXP="summary.jsp\?year=2001"> <COOKIE NAME="group" VALUE="asia" /> </ADVANCEDSELECTOR> <ACTION /> </OBJECT> <OBJECT> <ADVANCEDSELECTOR URIPREFIX="/image/" URIEXP="summary.*\.gif$" /> <ACTION /> </OBJECT> </INVALIDATION>
Invalidation response:
<?xml version="1.0"?> <!DOCTYPE INVALIDATIONRESULT SYSTEM "internal:///WCSinvalidation.dtd"> <INVALIDATIONRESULT VERSION="WCS-1.0"> <OBJECTRESULT> <ADVANCEDSELECTOR URIPREFIX="/global/sales/" URIEXP="summary.jsp\?year=2001" > <COOKIE NAME="group" VALUE="asia" /> </ADVANCEDSELECTOR> <RESULT ID="1" STATUS="SUCCESS" NUMINV="2"/> </OBJECTRESULT> <OBJECTRESULT> <ADVANCEDSELECTOR URIPREFIX="/image/" URIEXP="summary.*\.gif$" > </ADVANCEDSELECTOR> <RESULT ID="2" STATUS="SUCCESS" NUMINV="14"/> </OBJECTRESULT> </INVALIDATIONRESULT>
The following message invalidates all documents under the /images/
directory:
<?xml version="1.0" ?> <!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd"> <INVALIDATION VERSION="WCS-1.0"> <OBJECT> <ADVANCEDSELECTOR URIPREFIX="/images/"/> <ACTION REMOVALTTL="0"/> </OBJECT> </INVALIDATION>
Invalidation response:
<?xml version="1.0"?> <!DOCTYPE INVALIDATIONRESULT SYSTEM "internal:///WCSinvalidation.dtd"> <INVALIDATIONRESULT VERSION="WCS-1.0"> <OBJECTRESULT> <ADVANCEDSELECTOR URIPREFIX="/images/"/> <RESULT ID="1" STATUS="SUCCESS" NUMINV="125"/> </OBJECTRESULT> </INVALIDATIONRESULT>
The following message invalidates all documents under /contacts/
directory whose file names ends in .html
and uses cookie name cust
with a value of oracle
:
<?xml version="1.0" ?> <!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd"> <INVALIDATION VERSION="WCS-1.0"> <OBJECT> <ADVANCEDSELECTOR URIPREFIX="/contacts/" URIEXP="\.html$"> <COOKIE NAME="cust" VALUE="oracle"/> </ADVANCEDSELECTOR> <ACTION REMOVALTTL="0"/> </OBJECT> </INVALIDATION>
Invalidation response:
<?xml version="1.0"?> <!DOCTYPE INVALIDATIONRESULT SYSTEM "internal:///WCSinvalidation.dtd"> <INVALIDATIONRESULT VERSION="WCS-1.0"> <OBJECTRESULT> <ADVANCEDSELECTOR URIPREFIX="/contacts"/> URIEXP="\.html$"> <COOKIE NAME="cust" VALUE="oracle"/> </ADVANCEDSELECTOR> <RESULT ID="1" STATUS="SUCCESS" NUMINV="45"/> </OBJECTRESULT> </INVALIDATIONRESULT>
The following message invalidates all documents under /
.
<?xml version="1.0" ?> <!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd"> <INVALIDATION VERSION="WCS-1.0"> <OBJECT> <ADVANCEDSELECTOR URIPREFIX="/"/> <ACTION REMOVALTTL="0"/> </OBJECT> </INVALIDATION>
Invalidation response:
<?xml version="1.0"?> <!DOCTYPE INVALIDATIONRESULT SYSTEM "internal:///WCSinvalidation.dtd"> <INVALIDATIONRESULT VERSION="WCS-1.0"> <OBJECTRESULT> <ADVANCEDSELECTOR URIPREFIX="/"/> <RESULT ID="1" STATUS="SUCCESS" NUMINV="17"/> </OBJECTRESULT> </INVALIDATIONRESULT>
To better understand the relationship of the URIPREFIX
and URIEXP
attributes, consider the examples that follow.
To invalidate sample.gif
files within /cec/cstage/graphic*
directories, use the following syntax:
<ADVANCEDSELECTOR URIPREFIX="/cec/cstage/"
URIEXP="graphic.*/sample\.gif">
</ADVANCEDSELECTOR>
Note that ".*" in "graphic.*/sample\.gif
" are regular expression characters that match all directories starting with graphic
. The ".
" in "sample\.gif
" is escaped for a literal interpretation.
If you used the following syntax, Oracle Web Cache would try to locate a directory named graphic*
:
<ADVANCEDSELECTOR URIPREFIX="/cec/cstage/graphic*/"
URIEXP="sample\.gif">
</ADVANCEDSELECTOR>
To invalidate documents contained within /cec/cstage?ecaction=viewitem
, use the following syntax:
<ADVANCEDSELECTOR URIPREFIX="/cec/"
URIEXP="c
stage\?ecaction=viewitem"> </ADVANCEDSELECTOR>
Note that "?" is escaped with a backslash.
URLs such as /cec/cstage?ecaction=viewitem&zip=94405
and /cec/cstage?ecaction=viewitem&zip=94305
match and are invalidated, but /usa/cec/cstage?ecaction=viewitem&zip=94209
does not match and is not invalidated.
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 event_log
and is stored in $ORACLE_HOME/webcache/logs
on UNIX and ORACLE_HOME
\webcache\logs
on Windows.
Events are formatted into the following fields:
Timestamp Information/Warning/Error Message
The following shows an event log excerpt with successful startup entries:
14/May/2001:11:34:15 -0800 -- Information: Maximum number of file/socket descriptors set to 950. 14/May/2001:18:34:15 +0000 -- Information: Maximum connections possible are 900 14/May/2001:18:34:15 +0000 -- Information: Listening on ADMINISTRATION port 4000 address 0.0.0.0 14/May/2001:18:34:15 +0000 -- Information: The admin server started successfully 14/May/2001:11:34:15 -0800 -- Information: Maximum number of file/socket descriptors set to 950. 14/May/2001:18:34:15 +0000 -- Information: Maximum connections possible are 900 14/May/2001:18:34:18 +0000 -- Information: Listening on NORM port 1100 address 0.0.0.0 14/May/2001:18:34:18 +0000 -- Information: Listening on INVALIDATION port 4001 address 0.0.0.0 14/May/2001:18:34:18 +0000 -- Information: Listening on STATISTICS port 4002 address 0.0.0.0 14/May/2001:18:34:21 +0000 -- Information: The cache server started successfully 14/May/2001:18:34:22 +0000 -- Information: The cache server is started by the admin server at startup
The following 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.
14/May/2001: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/May/2001:16:37:41 -0800 -- Error: Failed to start the server. 14/May/2001:16:37:41 -0800 -- Error: The server could not initialize 14/May/2001:16:37:41 -0800 -- Information: The server is exiting
The following shows an event log excerpt with an event associated with an invalidation request for the removal of document personal.htm
:
14/May/2001:22:52:52 -0500 -- Information: <Invalidation>1 URLs with prefix personal.htm have been successfully invalidated.
The following shows an event log excerpt with an XML invalidation message error. In this example, Oracle Web Cache is unable to parse the message:
Example: Errors in the XML parsing. Note: The configuration files and invalidation files use XML files. 14/May/2001:10:55:26 -0500 -- Error: Invalidation XML Buffer cannot be parsed. 14/May/2001:10:55:26 -0500 -- Error: XML parsing error.
The following shows an event log excerpt with typical shutdown entries:
14/May/2001:11:16:55 -0700 -- Information: SIGTERM caught - program will shut down once all connections are complete. 14/May/2001:11:16:55 -0800 -- Information: SIGTERM caught - program will shut down once all connections are complete. 14/May/2001:11:16:55 -0700 -- Information: The server is exiting 14/May/2001:11:16:55 -0800 -- Information: The server is exiting
To list just the errors in the event log, use grep
on UNIX. For example:
grep " Error:" error*
To list errors by the current day, enter grep " Error:" event_log | grep "dd/mon/yyyy
". For example:
grep " Error:" event_log | grep "19/May/2001"
To list errors by the current day and hour, enter grep " Error:" event_log | grep "dd/mon/yyyy:
hh"
.
To establish event log configuration settings:
The Event Logging page appears in the right pane.
The Change Options for Event Logging dialog box appears.
Verbose event logs are used for debugging purposes. Therefore, select Yes if recommended by Oracle Support Services.
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 ORACLE_HOME
\webcache\logs
on Windows. 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.
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 enter.
Table 8-3 XLF Fields for Access Logs
Field | Description |
---|---|
|
Information about the user agent originating the request |
|
Allows the client to specify the address (URI) of the resource from which the Request-URI was obtained |
|
Username if the request contained an attempt to authenticate |
|
Content length of the transferred document |
|
Date at which the transaction completed |
|
Time at which the transaction completed |
time-end |
Time at which the transaction ended |
time-start |
Time at which the transaction started |
|
Amount of time taken (in seconds) for transaction to complete |
|
Client's IP address and port |
|
Oracle Web Cache's IP address and port |
|
Oracle Web Cache-to-client HTTP request method ( |
|
Oracle Web Cache-to-client HTTP status code:
See Also: |
|
Client-to-Oracle Web Cache URI |
|
Client-to-Oracle Web Cache stem portion of URI, omitting the query |
|
Client-to-Oracle Web Cache query portion of URI, omitting the stem |
|
|
The order in which fields are entered determines the order in which the fields are logged.
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
Note that entered XLF fields are not added to the CLF default. If you want to use the CLF fields in addition to XLF fields, you must enter them.
The access log that follows uses 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.
138.2.213.146 - - [19/May/2001:10:27:42 -0500] "GET /~ssandrew/personal.htm HTTP/1.0" 200 2438 138.2.213.146 - - [19/May/2001:10:27:54 -0500] "GET /~ssandrew/personal.htm?UserName=Bob HTTP/1.0" 200 2438 138.2.213.146 - - [19/May/2001:10:47:30 -0500] "GET /~ssandrew/count.sh HTTP/1.0" 403 289 138.2.213.146 - - [19/May/2001:10:47:34 -0500] "GET /~ssandrew/sbin/count.sh HTTP/1.0" 200 321 138.2.213.146 - - [19/May/2001:10:47:41 -0500] "GET /sbin/count.sh HTTP/1.0" 200 321 138.2.213.146 - - [19/May/2001:11:34:23 -0500] "GET /cache.htm HTTP/1.0" 200 250 138.2.213.146 - - [19/May/2001:11:38:23 -0500] "GET /cache.htm HTTP/1.0" 304 0 138.2.213.146 - - [19/May/2001:11:38:48 -0500] "GET /cache.htm HTTP/1.0" 304 0 206.223.27.37 - - [19/May/2001:15:14:29 -0500] "GET /~ssandrew/personal.htm?UserName=Joe HTTP/1.0" 200 2438 206.223.27.37 - - [19/May/2001:15:17:12 -0500] "GET /~ssandrew/personal.htm?UserName=Shehzaad HTTP/1.0" 200 438 144.25.223.39 - - [19/May/2001:15:30:34 -0500] "GET /htdocs/coelist.html HTTP/1.0" 200 4219 144.25.223.39 - - [19/May/2001:15:30:34 -0500] "GET /images/redheaderbanner.gif HTTP/1.0" 200 1226 138.2.213.146 - - [19/May/2001:10:49:44 -0500] "GET /pls/coe/find_via_post HTTP/1.0" 200 1119 138.2.213.146 - - [19/May/2001:10:49:44 -0500] "GET /ows-img/chalk.jpg HTTP/1.0" 404 284 130.35.35.21 - - [20/May/2001:00:36:35 -0500] "GET /images/support.jpg HTTP/1.0" 206 3106 130.35.35.21 - - [20/May/2001:00:36:35 -0500] "GET /images/ani_coe.gif HTTP/1.0" 206 73118
The following shows an access log excerpt in which there are two Web browser reloads, followed by two shift reloads, and two more reloads:
138.2.213.146 - - [19/May/2001:11:04:24 -0500] "GET /cache.htm HTTP/1.0" 200 250 138.2.213.146 - - [19/May/2001:11:04:26 -0500] "GET /cache.htm HTTP/1.0" 200 250 138.2.213.146 - - [19/May/2001:11:29:24 -0500] "GET /cache.htm HTTP/1.0" 304 0 138.2.213.146 - - [19/May/2001:11:29:25 -0500] "GET /cache.htm HTTP/1.0" 304 0 138.2.213.146 - - [19/May/2001:11:29:30 -0500] "GET /cache.htm HTTP/1.0" 200 250 138.2.213.146 - - [19/May/2001:11:29:35 -0500] "GET /cache.htm HTTP/1.0" 200 250
The following 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.
38.2.213.146 - - [19/May/2001:10:47:30 -0500] "GET /~ssandrew/count.sh HTTP/1.0" 403 289 138.2.213.146 - - [19/May/2001:10:47:34 -0500] "GET /~ssandrew/sbin/count.sh HTTP/1.0" 200 321
The following 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.
138.2.213.146 - - [19/May/2001:10:49:44 -0500] "GET /pls/coe/find_via_post HTTP/1.0" 200 1119 138.2.213.146 - - [19/May/2001:10:49:44 -0500] "GET /ows-img/chalk.jpg HTTP/1.0" 404 284
The following 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 an HTTP status code of 304, indicating that document has not been modified and does not need to be returned again.
138.2.213.146 - - [19/May/2001:11:34:23 -0500] "GET /cache.htm HTTP/1.0" 200 250 138.2.213.146 - - [19/May/2001:11:38:23 -0500] "GET /cache.htm HTTP/1.0" 304 0 138.2.213.146 - - [19/May/2001:11:38:48 -0500] "GET /cache.htm HTTP/1.0" 304 0
To enable access logging:
The Access Logs page appears in the right pane.
The Change Options for Access Logs dialog box appears.
access_log.
yyyymmdd
and write new log information to access_log
.
If you have a high-volume site, increase the frequency.
Separate fields by a space.
To disable access logging:
The Access Logs page appears in the right pane.
The Change Options for Access Logs dialog box appears.
|
Copyright © 2001 Oracle Corporation. All Rights Reserved. |
|