Ruediger Pluem wrote:
On 01/19/2007 05:49 PM, Scott MacVicar wrote:
I already have a patch that we're using in production, attached are
patches for the 2.2 and trunk.
I was under the impression that there wasn't any interest in a patch
like this hence I've not opened an issue to get this integrated into the
main package.
The option is CacheStoreQueryString.
The option you introduce does not really solve Fredrik's problem.
Your patch allows responses to requests with a query string to be cached
if the response does not contain an Expires header.
As far as I understood him the responses get cached (they seem to contain
an Expires header), but he wants to avoid that the query string gets
incorporated in the cache key. E.g.
/abc.html?x=a
/abc.html?x=b
result in two different cache entities. He wants them to be the same, or more
generally he wants all adjustments that have been made to the URI / query string
during the processing to be considered for the generation of the cache key.
Currently the original URI / query string is used for this.
BTW: Although it is not exactly the same your problem can be solved without
the patch by either:
- Making the content handler (whether in httpd or somewhere else) set an Expires
header in the response.
- If this is not possible let mod_expires set one.
Regards
Rüdiger
We did use mod_expires but the Expires header was being passed on to the
client, mod_headers didn't appear to be able to unset this during tests.
The reason for our desire to cache is that a version number is used in
the query string and incremented when appropriate on the resource.
Most browsers seem to ignore RFC2616 13.9 in regards to the query string
being present in the URI.
Apologies for not getting the gist of the thread.
Scott
