Oracle Web Cache Release Notes Release 1.0.2.3.0 ************************************************************************ Copyright (C) Oracle Corporation 2000 This software/documentation contains proprietary information of Oracle Corporation. It is provided under a license agreement containing restrictions on use and disclosure and is also protected by copyright law. Reverse engineering of the software is prohibited. If this software/documentation is delivered to a U.S. Government Agency of the Department of Defense, then it is delivered with Restricted Rights and the following legend is applicable: RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of DFARS 252.227-7013, Rights in Technical Data and Computer Software (October 1988). If this software/documentation is delivered to a U.S. Government Agency not within the Department of Defense, then it is delivered with "Restricted Rights," as defined in FAR 52.227-14, Rights in Data - General, including Alternate III (June 1987). Oracle Corporation, 500 Oracle Parkway, Redwood City, CA 94065. The information in this document is subject to change without notice. If you find any problems in the documentation, please report them to us in writing. Oracle Corporation does not warrant that this document is error free. Oracle is a registered trademark of Oracle Corporation, Redwood City, California. All trade names referenced are the service mark, trademark, or registered trademark of the respective manufacturer. ************************************************************************ TABLE OF CONTENTS 1.0 Configuring Oracle Web Cache 2.0 Oracle Web Cache Limitations 3.0 Netscape Limitations 4.0 Oracle Application Server Limitations 5.0 File Descriptor Limitations 6.0 TCP Tuning 7.0 Oracle Web Cache Watchdog 8.0 Oracle Web Cache Default Ports 9.0 Oracle Web Cache Usage Examples 10.0 How to Configure Oracle Web Cache to Listen on Port < 1024 11.0 Where to Find More Information and Patch Downloads 12.0 Enhancements 13.0 Known Bugs 14.0 Bugs Fixed in Version 1.0.2.1.0 15.0 Bugs Fixed in Version 1.0.2.2.0 15.0 Bugs Fixed in Version 1.0.2.3.0 ************************************************************************ 1.0 Configuring Oracle Web Cache To start initial Oracle Web Cache configuration: 1. If not currently logged on to the Oracle Web Cache computer, log in with the user ID of the user that performed the installation. 2. Start Oracle Web Cache. From the command line, enter: webcachectl start 3. Start Oracle Web Cache Manager: a. Point your browser to the following URL: http://web_cache_hostname:4000/ b. When prompted for the administrator user ID and password, enter administrator for the user name and the appropriate password. The first time you log in, the password is administrator. See Also: Oracle Web Cache Administration and Deployment Guide (available at http://otn.oracle.com/products/ias) for complete configuration coverage Note: Oracle Web Cache uses two configuration files: webcache.xml and internal.xml. These configuration files should NEVER be edited. Editing of these configuration is not supported and may cause problems in Oracle Web Cache. (See section 7.1 for exception). 2.0 Oracle Web Cache Limitations -------------------------------- 2.1 HTTP Range Requests and Multi-Part Responses Certain HTTP browsers will send Range headers in HTTP requests. In response to requests of this type, an application Web server may respond with a multi-part document or a document in its entirety. In this release, Oracle Web Cache cannot cache HTTP multi-part responses to HTTP Range requests. If the application Web servers that Oracle Web Cache sends HTTP requests to return certain documents in multi-part format, configure these documents as non-cacheable through the Administering Web Sites > Cacheability Rules section of the Oracle Web Cache Manager interface. For example, certain browsers send Range requests for PDF documents; therefore, the cacheability rules for all PDF documents should be set non-cacheable. 2.2 Personalized Pages When configuring cacheability rules, you can optionally enable Oracle Web Cache to replace personalized information in a cached document with user-specific personalized information in HTTP requests. This way, one cached personalized page can be reused for any user, improving performance significantly. In enabling this personalization feature, you can enable Oracle Web Cache to look for personalized information in special tags in the HTTP response or in all HTML links (often known as HREF) in the HTTP response. In this release, Oracle Web Cache looks for personalized information in both the special tags and in the HREF HTML links. Therefore, while editing/creating a cacheability rule, if you select YES in the Personalized Pages section, the selection in the subsection should always be "pages contain HREFs that are session encoded URLs." Selection of the other option, "pages do not contain HREFs that are session encoded URLs" is ignored. All personalized pages are always parsed for session-encoded URLs. 2.3 Application Web Server Recovery Oracle Web Cache can support multiple (up to 100) application Web servers. If any configured application Web server fails to serve requests from Oracle Web Cache for several times in a row, the server will be removed from application Web server load balancing list. However, Oracle Web Cache will try to detect the recovery of all failed Web servers periodically. In this release, it is hard-coded that Oracle Web Cache will remove an application Web server from load balancing list after 5 consecutive request failures. Oracle Web Cache will then attempt to detect Web server recovery every 60 seconds. 2.4 Default Buffer Sizes Oracle Web Cache uses buffered logging. The default buffer size is 2 KB. The default document buffer block size is 32 KB. The default document header buffer block size is 4 KB. These default sizes should be sufficient for most deployment. If you need to change any of these default sizes, please contact Oracle Support Services or consultants. 2.5 Insufficient Input Checking in Oracle Web Cache Manager The Oracle Web Cache Manager does not enforce the same level of consistency checking upon receiving configuration input that Oracle Web Cache does upon starting up. Therefore, there may be instances where configuration changes are accepted by the Oracle Web Cache Manager, but Oracle Web Cache does not start up with the resulting configuration. This is especially a problem when the Admin server itself is shut down (using webcachectl stop) after applying bad configuration changes. In that case, the Oracle Admin Server itself will not be able to start up, and the Oracle Web Cache Manager will become inaccessible. The workaround is: # webcachectl repair This will restore the previous version of the configuration. 2.6 Maximum number of connections This release of Oracle Web Cache can handle a maximum of 1024 file/socket descriptors. The maximum number of incoming connections is: [1024 - 20 (for internal file management) - (sum of origin server capacities)]. A patch to remove this limitation will be posted to the Oracle Technology Network web site soon. See Section 11.0. 3.0 Netscape Limitations ------------------------ Oracle Web Cache can optionally compress a cached document so that serving subsequent HTTP requests requires less network bandwidth. However, certain versions of the Netscape Navigator browsers do not support compressed JavaScripts and other non-HTML documents. If you plan to support Netscape Navigator for your Web site, please make sure in your cacheability rules that only cached HTML file are compressed. 4.0 Oracle Application Server Limitations ----------------------------------------- 4.1 Oracle Web Cache with Oracle Application Server on the same computer NOTE: This limitation applies to Oracle Application Server using the Oracle Web Listener ONLY. This does not apply to other listeners used with Oracle Application Server. 4.1.1 Introduction 4.1.1.1 Oracle Web Listener and the Host header Oracle Application Server, when used specifically with the Oracle Web Listener, strictly enforces virtual-host checking using the "Host" header, that is sent by almost all browsers. The Host header contains the string ":" where " and are as entered in the location bar of the browser, even if the in the location bar is an IP address. If the Oracle Web Listener receives a Host header that does NOT match an entry in the Host Name and Port columns of the "Network" section of the configuration (corresponding to the [Multiport] section in the sv*.cfg configuration file for the listener), it returns a HTTP error code 400 with the message: "The request did not specify a valid virtual host". 4.1.1.2 Deployments This limitation applies to the following deployments: 1) In Oracle Application Server 4.x, this is strictly enforced for HTTP/1.1 requests only. For HTTP/1.0 requests, only the hostname has to match an entry in the Network section. The port number in the Host header does not matter. 2) Oracle Web Listener, as shipped with Oracle Web Application Server 3.0 enforces this strictly for all HTTP requests, that is HTTP/1.0 and HTTP/1.1. 4.1.1.3 Entries for Network In order to make an Oracle Web Listener recognize and accept a Host header, a corresponding entry must be added to the "Network" section for that listener. When you add an entry with hostname h1 and port p1, h1 is ONLY used to match incoming Host headers and does not otherwise affect the operation of the listener. In fact, h1 does not even need to be a DNS host name of the computer. However, p1 is used as a port that the Oracle Web Listener tries to listen on. Hence there should be no other process on the computer listening on port p1. 4.1.2 Oracle Web Cache behavior Oracle Web Cache does NOT change the Host header that it receives as part of a request when relaying that request to the Application Web Server. If you set up Oracle Web Cache to listen on port 1100 on a computer with DNS hostname m1 and the application web server is on computer m2 on port 80, and you use a browser to access http://m1:1100/, the Host header received by Oracle Web Cache is "Host: m1:1100". This is exactly the Host header that will be received by the application Web server. 4.1.3 What Restrictions Does This Imply? If you are using Oracle Application Server with the Oracle Web Listener as your application Web server, this means that the host header sent to Oracle Web Cache MUST be recognized by the Oracle Web Listener, that is, there must be a corresponding entry in the "Network" section. 4.1.3.1 Restriction In Browser Testing Mode If you are using Oracle Web Cache's host name and port in your browser directly, and if Oracle Web Cache and the Oracle Web Listener are on the SAME COMPUTER, the Oracle Web Listener will need to accept Oracle Web Cache's host name and port number in the Host header, and for that to happen Oracle Web Cache's port number will need to appear in the Network section of the Listeners configuration. This would mean that both Oracle Web Cache and the Oracle Web Listener will try to listen on that port, which is not possible. See Also: Section 4.1.1.3 Hence in testing mode, when you are using your browser to directly connect to Oracle Web Cache, then Oracle Web Cache and the Oracle Web Listener, cannot be on the same computer. 4.1.3.2 Restriction and Solution In Deployment mode In order to deploy Oracle Web Cache and the Oracle Web Listener on the same computer, there has to be a port-translating switch between the browser and Oracle Web Cache that translates the port number to which the browser connects to Oracle Web Cache's listening port. For example, assume that Oracle Web Cache is listening on port 1100 on computer m1.aaa.com, and Oracle Web Listener is the application Web server listening on port 80 on the same computer m1.aaa.com. In this example, the user enters http://www.aaa.com/ in the browser. The browser will attempt to connect to port 80 on www.aaa.com. www.aaa.com should be resolved via DNS to your switch, which should redirect requests for www.aaa.com on port 80 to computer m1 on port 1100. Note that the host header will be: "Host: www.aaa.com:80". Oracle Web Cache will forward requests as needed to computer m1 port 80 i.e. the Oracle Web Listener. For the Oracle Web Listener to accept this Host header, you will need to have added an entry to Network containing Host Name www.aaa.com and Port 80. See Also: 4.1.1.3 for how this can be done on computer m1 5.0 File Descriptor Limitations ------------------------------- On most UNIX platforms there is a hard limit to how many file descriptors a process can open. This number is normally 1024 but is configurable. In this release, Oracle Web Cache can use up to 1024 file descriptors or your system's hard limit to open file descriptors, whichever is lower. If your system's hard limit is less than 1024, you can increase it up to 1024 to get better scalability. In additional, out of all file descriptors available to Oracle Web Cache, a small portion are used for logging, administration, application Web server requests, and so on. Therefore, the maximum number of concurrent open connections from front-end HTTP clients that the Cache can handle is less than the number of file descriptors available to it. 6.0 TCP Tuning -------------- If you want Oracle Web Cache to handle large number of concurrent HTTP requests, you may need to tune your operating system's TCP settings, such as the maximum TCP connection queue length. See Also: http://www.rvs.uni-hannover.de/people/voeckler/tune/EN/tune.html for information about how to tune Solaris 2.x TCP parameters. In particular, if you run stress tests against Oracle Web Cache and continuously open more TCP connections from one client computer to Oracle Web Cache, you may experience periodic oscillation of throughput. This is usually caused by TCP connection TIME_WAIT in your operation system. In real world deployment, this is not an issue since it is unlikely that one client will generate a huge number of connections. In case of denial of service attack, availability problems usually arise in the network layer in your operating system. For example, if one client generates large number of connections, TCP connection problems generally arise in your operating system. The following is an example shell script that sets some of the TCP parameters for Solaris 2.x: #!/usr/bin/bash -x /usr/sbin/ndd -set /dev/tcp tcp_conn_req_max_q 10240 /usr/sbin/ndd -set /dev/tcp tcp_conn_req_max_q0 10240 /usr/sbin/ndd -set /dev/tcp tcp_xmit_hiwat 32768 /usr/sbin/ndd -set /dev/tcp tcp_recv_hiwat 32768 /usr/sbin/ndd -set /dev/tcp tcp_time_wait_interval 1000 7.0 Oracle Web Cache Watchdog ----------------------------- Oracle Web Cache has two major components: the Admin Server and the Cache Server. The Admin Server handles administrative tasks and the Cache Server handles caching and HTTP requests. The Admin Server also has a watchdog feature that periodically (every 5 seconds) pings the Cache Server, if started, for the URI '/'. Therefore, the access and event logs will contain several entries for '/'. This is caused by the watchdog in the Admin Server. If a started Cache Server fails, the watchdog will attempt to restart the Cache Server. However, if you stop the Cache Server from the administration page (http://:/), watchdog will stop pinging. If the Cache Server is not configured with a valid application Web server, then watchdog pinging will fail every time, causing error output in event log. To stop this, either configure valid application Web servers, or stop the Cache Server through the administration page (http:// :/). 7.1 Enabling the Watchdog -------------------------- In release 1.0.2.1, the watchdog has been disabled by default. You can enable the watchdog by hand-editing the 'webcache.xml' file. Since this is an automatically generated and processed file, you must be very careful in making this change. Add the line: before the last line (which should be ""). 8.0 Oracle Web Cache Default Ports ---------------------------------- During installation, Oracle Web Cache is configured to use the following default TCP ports: - Administration: 4000 - HTTP request: 1100 - Invalidation: 4001 - Statistics: 4002 - Application Web Server: localhost:7777 At the end of installation, Oracle Web Cache will attempt to start. Depending on your environment (port conflicts, file/directory permissions, and so on), Oracle Web Cache Admin Server and/or Cache Server may fail to start. If the Admin Server could not start because the default administration port is already in use by other running applications, you need to change the administration port in $ORACLE_HOME/webcache/webcache.xml. Find the line and change "4000" to an unused port (such as "3999"). Then run $ORACLE_HOME/webcache/bin/webcachectl start to start the Admin Server and the Cache Server. Note: This is the ONLY case where you need to edit the Oracle Web Cache configuration file directly. Except for this single scenario, you should NEVER edit any configuration files. If the Admin Server is started but the Cache Server could not start, point your browser http://:/ to reconfigure the Cache Server, and then start the Cache Server from the WWW administration page. If any of the above port settings conflict with existing settings in the installed computer, please reconfigure through http://:/. For example, if Oracle Web Cache is installed on a computer named server1, then you can reconfigure through http://server1:4000/. Please note that after reconfiguring the administration port, you must restart Oracle Web Cache Admin Server. After reconfiguring any other ports, you must restart Oracle Web Cache Cache Server. To restart the Admin Server under Unix, execute the following commands: $ORACLE_HOME/webcache/bin/webcachectl stop $ORACLE_HOME/webcache/bin/webcachectl start 9.0 Oracle Web Cache Usage Examples ------------------------------------ To find examples of how to use Oracle Web Cache, read $ORACLE_HOME/webcache/examples/README.examples. 10.0 How to Configure Oracle Web Cache to Listen on Port < 1024 --------------------------------------------------------------- On most Unix platforms, a process without root privilege cannot listen on ports < 1024. If you want to configure Oracle Web Cache to listen on port < 1024 such as the usual port 80 and you do not want Oracle Web Cache to keep running with root privilege, follow the following steps: (1) Through the Web Cache Manager, change process identity to the desired running process identity, such as nobody/nobody; change Oracle Web Cache listening port to the desired port, such as 80; (2) log in as root; (3) change the owner of the executable 'webcached' to root; $ chown root /opt/oracle/webcache/bin/webcached (4) change the group of the executable 'webcached' to the group id of the desired running process identity, such as nobody: $ chgrp /opt/oracle/webcache/bin/webcached (5) add set-user-id permission to the executable 'webcached'; $ chmod u+s /opt/oracle/webcache/bin/webcached (6) exit from root; (7) start Oracle Web Cache through webcachectl. Oracle Web Cache should be listening on the desired port with the desired process identity (nobody/nobody). $ /opt/oracle/webcache/bin/webcachectl start 11.0 Where to find more information and patch downloads ------------------------------------------------------- To find more information, online documentation, latest news, and patch downloads of Oracle Web Cache, visit http://otn.oracle.com/products/ias and/or http://metalink.oracle.com. 12.0 Enhancements ----------------- Enhancements in Version 1.0.2.1.0 --------------------------------- 12.1 Watchdog. See section 7.1. 12.2 Access logging can now be disabled using the Web Cache Manager. You can disable access logs in the Administering Web Sites > Access Logging page. Note: The online help does not reflect this new feature. 12.3 Event logs now support an optional verbose mode. This mode, when enabled, logs typical events, plus events related to application Web server requests. Verbose event logs are used for debugging purposes and should only be enabled if recommended by Oracle Support Services. You can enable verbose event logging in the Administering Oracle Web Cache > Event Logging page of the Oracle Web Cache Manager. Enhancements in Version 1.0.2.3.0 --------------------------------- 12.4 When sending any HTTP response for a request from the cache (a.k.a. a cache hit), if this response object has session-encoded URLs in the body (For example, HTML links with session values in the URL) or personalized attributes (For example, a login user's name or his/her address info) and if the subsititution for any of these session values/personalized attributes does not exist in the request, WebCache 1.0.2.2.0 and earlier versions then consider this request a cache miss, thus will not use the cached object and request a response from the backend application web server. In 1.0.2.3.0, WebCache will, in this situtation, subsititute as much as possible and leave missing personalized attribute/session values empty. Therefore this request is now a cache hit. If you want to disable this feature, that is, require all necessary personalized attribute/session values to exist in the request for iti to be a cache hit, then you must define those personalized attributes/sessions as sessions and then define session-related caching rules for such requests. In the session-related caching rule, specific the response to be cacheable only if the request contains a session value. 13.0 Known Bugs -------------- Bug Number Description 1412247 Web Cache cannot cache HTTP multi-part responses to accept Range requests. See Also: Section 2.1 1412233 Parsing for personalized attributes is not separated from session-encoded URLs. There is no way for a user to specify that a particular response document should JUST be parsed for personalized tags or JUST for session information encoded in HREFs in the response body. See Also: Section 2.2 1416002 Oracle Web Cache Manager has insufficient sanity checking. See Also: Section 2.5 1411997 Oracle Web Cache adds white space to certain HTTP headers when forwarding requests to application Web Servers. For example, the incoming request header: Accept-Language: en-us,zh-hk;q=0.5 is forwarded as: Accept-Language: en-us, zh-hk; q=0.5 This is not a violation of the HTTP specification, which allows white space between tokens in a header. See RFC 2616, section 2.1, last paragraph titled "implied *LWS". However, an application Web server that does not tolerate this extra white space may fail. 1283804 Oracle Web Cache does not serve documents with a validity level greater than zero when the application Web server is down. Oracle Web Cache only serves stale documents (that is, documents with a validity between 1 and 9) when an application Web Web server has reached its capacity, not when it is merely unreachable. 1419774 Application web server load may exceed configured capacity when Oracle Web Cache uses MORE THAN ONE application web server. This may happen in three different scenarios: 1. Oracle Web Cache balances requests to application web servers by the configured capacities. On average the distribution of load will conform to each application web server's relative capacity. This is indicated by the "Total Requests Served" column in the Health Monitor page. Occasionally the concurrent load on some web servers may exceed the configured maximum capacity. This is indicated by the "Load:max" column in the Application Web Server Statistics page. 2. If an application web server is down, its load may be distributed over the other application web servers and this may raise the load on these remaining application web servers over their configured capacity. But the total load on all application web servers will not exceed the sum of the configured capacities. 3. If session-binding (stateful load balancing) is enabled, due to the stateful nature of load balancing, each web server's individual capacity may be violated but the total capacity will not be exceeded. 14.0 Bugs Fixed in Version 1.0.2.1.0 ------------------------------------ The following bugs have been FIXED in this version. The Description is an elaboration of the problem as reported. Bug Number Description 1414757 Cache size and total number of cached documents in Web Cache statistics page do not change after cache document removal (cache cleanup). But the relevant cached documents are removed correctly. 1414770 In XLF logging, the cs-uri-stem and cs-uri-query fields are logged incorrectly. The entire URI (including the query string) is logged for both these fields. 1414777 In XLF logging, the s-ip field, which is supposed to be the cache server's ip address, is incorrectly logged as 0.0.0.0 1287475 The HTTP method of the incoming request is not considered in delivering a cache hit, except in the case that the cache entry was initially created as a result of a POST. For example, if the cache was populated as a result of an initial GET request for the URL /cgi-bin/hello, a subsequent POST, PUT, or DELETE request for /cgi-bin/hello will cause a cache hit, and the result of the first request will be returned to the browser. However, if the initial request was a POST to /cgi-bin/hello, subsequent requests must be POSTs to hit the cached document. 1471497 If a document doesn't match any cacheability rule URL regular expressions, it is sometimes cached and served for requests arriving at the same moment. 1462928 In the admin GUI if a user clicks on "Apply changes" twice or if he clicks the button without making any changes to the config file, the original configuration file is deleted. 1454682 One file descriptor is leaked by the Admin Server every time Oracle Web Cache is stopped using the 'Web Cache Operations' screen. This leak will cause the admin server to eventually hang after the system limit for file descriptors has been reached. 1454835 Using the default caching rules provided with installation, Web Cache was incorrectly caching the mod_jserv demo IsItWorking applet. 1427857 When trying to change a URL association from the "Multiple Documents with Same URL by Cookies" page and trying to make an association by selecting a URL that is used by another cookie, Web Cache Manager reports an Internal Error. 1419253 The "Application Web Server Statistics" always shows Avg/Sec Load and Active Sessions as zero. 1428145 Choosing 'THIS MACHINE ONLY' in the 'Secure Subnets' section on the Security screen of Web Cache Manager blocks all access to the Web Cache Manager. 1417640 Having four or more Sessions/Personalized Attributes causes a core dump on accessing the cache. 1419279 Viewing 'Health Monitor' while the site is loaded causes the admin server (webcached -A) to take up 100% of the CPU. 1471878 There is no way to disable access logging from the Oracle Web Cache Manager. See section 12.2 1471894 The Watchdog, on incorrectly detecting a hang condition, continuously attempts to restart the cache. The attempt to start the cache fails since it is already up. (Though this has been fixed in 1.0.2.1, see also section 7.1 for additional information). 1471906 Excessive Event Logging. See section 12.3 15.0 Bugs Fixed in Version 1.0.2.2.0 ------------------------------------ The following bugs have been FIXED in this version. The Description is an elaboration of the problem as reported. Bug Number Description 1486357 When webcachectl is used to start/stop the cache server, the Web Cache Operations screen in the Web Cache Manager reports the wrong information about the status of the cache server. 1496124 The Health Monitor screen of Web Cache Manager sometimes returns error even when the cache server is running properly. 1503263 Web Cache core dumps after running long enough, or after level-0 invalidation. 1503290 The webcache.xml configuration file is removed after two clicks of the "Apply Changes" button in the Web Cache Manager top frame. 1508625 After the max connection limit has been reached, Web Cache doesn't listen on most ports even if the current connection count drops below limit. 1510513 Access logging configuration page in Web Cache Manager layout problem. 1510945 Potential memory access error when a failed application web server recovers. 1520719 Each invalidation message causes a file descriptor leak. 15.0 Bugs Fixed in Version 1.0.2.3.0 ------------------------------------ The following bugs have FIXED in this version. The Description is an elaboration of the problem as reported. Bug Number Description 1581068 When some Uris are configured to be cacheable with only the POST HTTP method , "POST" is not appended to the key, resulting in these documents being served out from the cache for other request methods also. 1581045 When a request is made for a cacheable document, if the response from the application web server contains a session cookie whose value is different from that in the request, web cache does not cache the response. 1569752 When WebCache requests documents from the origin server, it adds a trailing white space at the end of the HTTP request line which does not conform to RFC 1945. 1581660 The content within the personalized contents i'e within the and , cannot have hrefs. The WebCache parser fails when it has hrefs. 1581630 In case of cache hits with session/personalized attribute substitution, some HTTP response headers appear in the begining of the response body. 1581602 In some resonses with many set-cookie response headers, not all of them are stripped when cached. This is because calypso until 1.0.2.2.0 has a compiled suppport limit of 5 set-cookie headers in each cacheable document. This has been increased to 20 now. 1577907 In OS failover, a document header buffer is freed twice resulting in core dumps afterwards. 1570942 ClientIP address is not passed to backend webserver. 1530453 When post requests are cacheable, sometimes the post body is not appended to the cache document key. 1613054 Origin Server ping request and interval is not configurable. 1613012 Invalidation Response has an error when invalidating from the GUI. 1411997 When WebCache forwards client browser request to HTTP Server, it inserts spaces in some of the headers of the request. 1578800 WebCache dumps core while starting.