We're trying to introduce mod_cache usage into our application, and it's
working well, except that on a cache miss most response headers are either
overridden or simply discarded by Apache before they make it to the client.
This is particularly problematic for gzipped content, which is not decoded
correctly in this case. Let me show you:
$ curl -sS -D /proc/self/fd/2 --compressed http://neil2-dev-vote.polldev.com:8080/admin.php >/dev/null
HTTP/1.1 200 OK
Date: Tue, 01 Sep 2015 18:59:01 GMT
Server: Apache
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Etag: 1
X-Cache: MISS from neil2-dev-vote.polldev.com
X-Cache-Detail: "cache miss: attempting entity save" from neil2-dev-
vote.polldev.com
Transfer-Encoding: chunked
Content-Type: text/plain
$ curl -sS -D /proc/self/fd/2 --compressed http://neil2-dev-vote.polldev.com:8080/admin.php >/dev/null
HTTP/1.1 200 OK
Date: Tue, 01 Sep 2015 18:59:02 GMT
Server: AwesomeServer/1.0
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Etag: 1
Content-Encoding: gzip
X-Custom: foo
Vary: Accept-Encoding
Age: 0
X-Cache: HIT from neil2-dev-vote.polldev.com
X-Cache-Detail: "cache hit" from neil2-dev-vote.polldev.com
Content-Length: 3
Content-Type: text/plain
Here is the php script in the requests above:
<?
header("Content-Encoding: gzip");
header("Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT");
header("Etag: 1");
header("X-Custom: foo");
header("Content-Type: text/plain");
header("Server: AwesomeServer/1.0");
header("Vary: Accept-Encoding");
print "11\n";
?>
The script in question is strictly for testing this problem, aside from a very
short response body, all it does is set a variety of headers. From the curl
responses, we can see that one of three things is happening to the headers in
the cache miss situation. More specifically...
These headers are completely missing:
- Content-Encoding
- X-Custom
- Vary
These headers are overwritten:
- Server
These headers are passed through verbatim:
- Last-Modified
- Etag
- Content-Type
It's worth noting that on the initial cache miss, I've confirmed that the
actual on disk cache file is populated with the expected headers, and that on
cache hits, php-fpm is never contacted, so the actual caching portion of
mod_cache is working correctly.
Now, one thing that's particularly interesting is that if I switch back to
mod_php with prefork mpm, all of the headers set in the php script are passed
through verbatim (ie, the expected behaviour). I'm not keen on this approach
as my understanding is that mod_php is deprecated these days.
Here's the mod_cache config that I'm currently working with:
CacheRoot /tmp/httpd_cacheroot
CacheEnable disk /admin.php
CacheLock on
CacheHeader on
CacheDetailHeader on
CacheQuickHandler off
I have tried toggling all of the boolean mod_cache directives above, but that
didn't help.
The software versions involved are a fully updated CentOS 7, which for httpd
means:
Server version: Apache/2.4.6 (CentOS)
Server built: Aug 24 2015 18:11:25
I'm running out of ideas on how to solve this issue, but I'm not sure if it's
a configuration issue or an actual bug. Any ideas?
- Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|