Caching for Objects with Multiple Versions

Caching and Compressing Content 6-7 next request to the same origin server, the client includes the Cookie request-header field with the category cookie name and value that was received in the last response: Cookie:cookie=value Oracle Web Cache still forwards the request to the origin server, which responds with or without the Set-Cookie header. Oracle Web Cache then evaluates whether the cookie and its value set in the Set-Cookie response-header matches the cookie and its value set in the Cookie request-header. If the cookie and value match, then the response is cached. Oracle Web Cache consider the absence of the Set-Cookie header a match. If cookie and its value do not match, then the response is not cached. After versions of the object are cached, Oracle Web Cache uses the value of the cookie in the clients request to serve the appropriate version of the object to the client browser. Table 6–2 shows four different versions of same URL, http:www.dot.compage1.htm. The URL uses a cookie named user_type, which supports client requests that contain cookie values of Customer, Internal, and Promotional. You can configure Oracle Web Cache to recognize the user_type cookie, enabling Oracle Web Cache to cache three different objects. In addition, you can configure Oracle Web Cache to cache a fourth object for those requests that do not use a cookie. For those objects that have different versions based on HTTP request headers, configure caching rules that specify the HTTP request header. HTTP request headers enable clients to pass additional information about the request and about themselves. Oracle Web Cache uses the header to serve the appropriate version of the URL to clients. Oracle Web Cache supports all valid HTTP request headers. Table 6–3 lists the HTTP request-header fields supported by Fusion Middleware Control. You can specify any of the standard or other HTTP request-header fields with the Surrogate-Control response-header field. Note: Oracle Web Cache does not cache the Set-Cookie response header field. Table 6–2 Multiple-Version Object with Different Cookie Values Version URL Cookie NameValue 1 http:www.dot.compage1.htm user_type=Customer 2 http:www.dot.compage1.htm user_type=Internal 3 http:www.dot.compage1.htm user_type=Promotional 4 http:www.dot.compage1.htm No cookie Table 6–3 HTTP Request-Header Field Header Field Description Accept Specifies which media types are acceptable for the response Example: Accept: imagegif, imagex-xbitmap, imagejpeg, imagepjpeg, imagepng, Accept-Charset Specifies which character sets are acceptable for the response Example: Accept-Charset: iso-8859-1,,utf-8 6-8 Oracle Fusion Middleware Administrators Guide for Oracle Web Cache For configuration details, see Section 6.8.2 .

6.5.2 Caching for Objects with Embedded URL and POST Body Parameters

By default, Oracle Web Cache distinguishes origin server responses by the request URLs. However, if the request contains an embedded URL or POST body parameter, the request URL to the same page content is distinct for each session. Therefore, Oracle Web Cache caches responses for each of the distinct URLs. This can result in low cache hit rates and redundantly cached objects. By configuring Oracle Web Cache to ignore the value of embedded URL or POST body parameters, you enable Oracle Web Cache to serve one cached object to multiple sessions requesting the same page. Oracle Web Cache caches the response to the first request and serves subsequent requests for the page from its cache. Consider user Jane Doe accessing a page with a request URL of: https:oraclestore.oracle.comOA_HTMLibeCCtpSctDspRte.jsp?section=10103session_ID=33436 User John Doe accesses the same page with a request URL of: https:oraclestore.oracle.comOA_HTMLibeCCtpSctDspRte.jsp?section=10103session_ID=33437 In addition, this page contains the following POST body for Jane Doe and John Doe, respectively: section=1013 session_ID=3346 Accept-Encoding Restricts the content-encodings that are acceptable in the response Example: Accept-Encoding: gzip Accept-Language Specifies the set of languages that are preferred as a response Example: Accept-Language: en User-Agent Contains information about the client that initiated the request Example: User-Agent: Mozilla4.61 [en] WinNT; U Note: By default, Oracle Web Cache does not interpret the values of these HTTP request headers. If the values for two pages are different, Oracle Web Cache caches both pages separately. This issue is especially problematic with the User-Agent request header, whereby the browser type, version, and operating system can result in too many duplicate cache entries. For example, if one request sends an HTTP request-header field of User-Agent: Mozilla4.0 compatible; MSIE 5.5; Windows and another request sends an HTTP request-header field of User-Agent: Mozilla4.0 compatible; MSIE 5.0; Windows; DigExt for different versions of Internet Explorer, Oracle Web Cache serves two pages for the two requests. You can override this behavior for the User-Agent request header by configuring Oracle Web Cache to cache and serve the same page for the same browser type, as described in Section 6.8.4 . Table 6–3 Cont. HTTP Request-Header Field Header Field Description Caching and Compressing Content 6-9 section=1013 session_ID=3347 The only distinct part to the request URL and the POST body is the value of the session_ID parameter. Rather than caching and serving two versions of the same object, you can configure Oracle Web Cache to ignore the value of session_ID so that one cached object can be served to both users. To configure parameters to ignore, establish global parameters to be applied to all caching rules or site-specific parameters to be applied to caching rules for a specific site. See Section 6.8.3 .

6.5.3 Caching Error Responses

If there is a problem on the origin server that does not result in a 200 OK HTTP response status for a request that matches this rule, then Oracle Web Cache does not attempt to send the request to the origin server again. Instead, it serves the cached HTTP error, saving origin server resources for known bad responses. By default, Oracle Web Cache does not cache any non-200 OK HTTP responses. If you want these errors to be cached, then you must configure caching rules to specifically cache error responses. Oracle Web Cache caches the error pages according to the expiration policy of the rule. After the problem is resolved, invalidate the HTTP error responses. For configuration details, see Section 6.8.5 .

6.5.4 Caching for Objects with Sessions

You can specify how Oracle Web Cache serves requests with the existence or nonexistence of session cookies, embedded URL parameters, or POST body parameters. You can choose to: ■ Serve or not serve cached objects to requests that have a session cookie, embedded URL parameter, or POST body parameter ■ Serve or not serve cached objects to requests that do not have a session cookie, embedded URL parameter, or POST body parameter For example, if you want the first request of a new user to establish a session from the origin server, then choose to serve cached objects to requests that have the session cookie or parameter, but do not serve cached objects to requests that do not have the session cookie or parameter. When you choose to serve for both, you can then specify if requests with or without the session cookie or parameter can share the same cached object. Oracle Web Cache uses a default string for those requests without the cookie or parameter. For configuration details, see Section 6.8.6 .

6.5.5 Caching for Objects with Session-Encoded URLs

The section Section 6.5.2 describes how you can ignore the value of embedded URL or POST body parameters for objects with identical content for all sessions. However, in some cases, the HTML content of objects is programmed with hyperlink tags, such as A HREF=..., that contain embedded session information to distinguish users. These links are called session-encoded URLs. The use of session-encoded URLs results in responses that vary slightly from session to session. 6-10 Oracle Fusion Middleware Administrators Guide for Oracle Web Cache You can configure Oracle Web Cache to substitute sessions within HTML hyperlink tags with the session values obtained from a session cookie, embedded URL parameter, or POST body parameter. By configuring session value substitution in combination with ignoring the value of embedded URL parameters, you can configure Oracle Web Cache to cache one object for multiple sessions, even if the session parameter values in session-encoded URLs vary. Continuing with the example from Section 6.5.2 , assume that Jane Doe and John Doe are again assigned an embedded URL parameters of session_ID=33436 and session_ID=33437 by the origin server. The page shown in Figure 6–2 has several A HREF=... links that include the session_ID parameter. The Oracle Database Standard Edition link under the Oracle Database heading for Jane Doe uses the following HTML code: A HREF=http:oraclestore.oracle.comOA_ HTMLibeCCtpSctDspRte.jsp?section=10166session_ID=334326Oracle Database Standard EditionA The same link for John Doe uses the following HTML code: A HREF=http:oraclestore.oracle.comOA_ HTMLibeCCtpSctDspRte.jsp?section=10166session_ID=334327Oracle Database Standard EditionA By using the value of the session_ID embedded URL parameter, Oracle Web Cache substitutes the correct session information for Jane Doe and John Doe. Figure 6–2 Session-Encoded URLs After the cache is populated with a page that contains session-encoded URLs, other requests for the page are served from the cache, regardless of whether the request has Note: Oracle Web Cache does not cache the Set-Cookie response header field.