|
Problem(Abstract) |
This technote provides information on the NoCacheOnRange
directive.
The minimum release levels that support this directive are: 4.0.2.57,
5.0.2.36, 5.1.1.10, 6.0.2.0.
By default, when receiving a Range request from browsers, Caching Proxy
requires a full response from the back-end server. Caching Proxy removes
the Range header in the request and then forwards the request to the
back-end server. After the response is cached on the proxy server, the
subsequent requests for the same resources are served from the proxy
server, regardless of whether the requests are Range requests or not.
Usually, the default action of Caching Proxy improves performance and
gives clients shorter response times. However, if the response cannot be
cached, or if the response is very large, the default action decreases
performance. |
|
|
|
Resolving the
problem |
Use the NoCacheOnRange directive, which specifies no
caching for Range requests, to solve the problem that is described when
using the default configuration.
When you enable the directive globally in the ibmproxy.conf file, or if
you enable it as an option for the PROXY mapping rule, Caching Proxy
forwards the Range request-header to the back-end server. Caching Proxy
does not cache the 206 (partial content) response from the back-end
server.
The NoCacheOnRange directive can improve the proxy performance for the
following cases:
- The responses cannot be cached or updated frequently.
- The response time is critical for the application.
Syntax:
NoCacheOnRange [on | off]
Default:
off
You can also enable NoCacheOnRange in a proxy mapping rule; for example:
Proxy /not-cachable/*
http://server.com/no-cachable-resources/*
NoCacheOnRange |
|
|
|
|
Cross Reference information |
Segment |
Product |
Component |
Platform |
Version |
Edition |
Application Servers |
WebSphere Edge Server |
Caching Proxy |
Multi-Platform |
Edge Server 2.0 PTF2 |
|
Application Servers |
Runtimes for Java Technology |
Java SDK |
|
|
|
|
|
|