Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

SOLVED

Dispatcher Caching with Apache Compression causes bad ETag header

15473203
Level 2
Level 2

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.

1 Accepted Solution
15473203
Correct answer by
Level 2
Level 2

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) - St... .

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.

View solution in original post

0 Replies
15473203
Correct answer by
Level 2
Level 2

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) - St... .

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.

View solution in original post