The following reply was made to PR mod_proxy/4415; it has been noted by GNATS.
From: "Pulver, Victor" <[EMAIL PROTECTED]>
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>,
"'[email protected]'" <[email protected]>
Cc: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
Subject: RE: mod_proxy/4415: Cache entries are unnecessarily deleted as a
result of pragma: no-proxy
Date: Fri, 21 May 1999 09:21:50 -0700
I'd like to make an addition to the correction:
Add this change to the changes already entered:
664c700,703
< strlen(url) < 1024 && !ap_proxy_liststr(pragma, "no-cache") &&
---
> strlen(url) < 1024 &&
> #ifndef IGNORE_PRAGMA_NOCACHE
> !ap_proxy_liststr(pragma, "no-cache") &&
> #endif
Discussion:
RFC 1945, section 10.12 explains pragma:no-cache as follows:
"When the "no-cache" directive is present in a request message, an
application should forward the request toward the origin server even if it
has a cached copy of what is being requested. This allows a client to insist
upon receiving an authoritative response to its request. It also allows a
client to refresh a cached copy which is known to be corrupted or stale."
In the case of a (load balancing or caching) reverse proxy, one could argue
that the the proxy is actually a component of the origin server and that the
contents of its cache are authoritative. This proposed change uses a
preprocessor identifier, which if defined (e.g.,
EXTRA_CFLAGS=-DIGNORE_PRAGMA_NOCACHE) causes mod_proxy to ignore the
no-cache pragma. I chose to use a compile time variable rather than a
configuration parameter to avoid the extra overhead and because it would
probably be used only rarely.
