Dispatcher Caching with Apache Compression causes bad ETag header | Community
Skip to main content
15473203
Level 2
February 17, 2018
Solved

Dispatcher Caching with Apache Compression causes bad ETag header

  • February 17, 2018
  • 1 reply
  • 2077 views

With Apache compressing the cached documents in the dispatcher, the ETag is set like:

ETag: "796-56562d1294cfd-gzip"

and Apache compression is enabled with:

AddOutputFilterByType DEFLATE "image/svg+xml"

But when it is compared against the cached file, it always returns a 200 instead of a 304.

The dispatcher configuration documentation mentions enabling Apache compression in this way:

Configuring Dispatcher

But it breaks the 304 Not Modified functionality. How can Apache compression and dispatcher caching be used together without breaking this feature?

I'm using dispatcher module 4.2.3 and Apache 2.4.6.

Thanks.

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by 15473203

I guess I found out why this is happening, and it appears to be a bug with Apache 2.4 when Apache serves the file (like it would out of the dispatcher cache) it adds the ETag information with "-gzip" added to the end of the ETag. But it seems on the next request, the "-gzip" appended to the end makes Apache think the file is different since the file in the dispatcher cache has not been used gzipped yet. More discussion is at http - Apache is not sending 304 response (if mod_deflate and AddOutputFilterByType is enabled) - Stack Overflow .

I ended up adding FileETag None to the Apache config since I don't really care about the ETag response header anyways, and my content that is not cached by the dispatcher doesn have the ETag header anyways.

1 reply

15473203
15473203AuthorAccepted solution
Level 2
February 17, 2018

I guess I found out why this is happening, and it appears to be a bug with Apache 2.4 when Apache serves the file (like it would out of the dispatcher cache) it adds the ETag information with "-gzip" added to the end of the ETag. But it seems on the next request, the "-gzip" appended to the end makes Apache think the file is different since the file in the dispatcher cache has not been used gzipped yet. More discussion is at http - Apache is not sending 304 response (if mod_deflate and AddOutputFilterByType is enabled) - Stack Overflow .

I ended up adding FileETag None to the Apache config since I don't really care about the ETag response header anyways, and my content that is not cached by the dispatcher doesn have the ETag header anyways.