Browser cache compression + Nginx = bug

Resolved crewstyle
(@crewstyle)

8 years, 4 months ago
Hi there,

When you enable the general Browser cache compression (option ID: browsercache_compression) on an Nginx web server, here is what you’ve got as a configuration in the nginx.conf custom file:
```
location ~ /wp-contents/cache/page_enhanced.*gzip$ {
    gzip off;
    types {
        text/xml xml_gzip
    }
    default_type text/html;
    expires modified 3600s;
    add_header X-Powered-By "W3 Total Cache/0.9.6";
    add_header Vary "Accept-Encoding, Cookie";
    add_header Pragma "public";
    add_header Cache-Control "max-age=3600, public";
    add_header Content-Encoding gzip;
}
```
As you can see, a semicolon is missing in the instruction text/xml xml_gzip
This bug prevents the server from restarting.

Could you please check this and fix it?

Best regards,

Viewing 7 replies - 1 through 7 (of 7 total)

Thread Starter crewstyle
(@crewstyle)

8 years, 4 months ago
Hello,

It seems the bug is in the PgCache_Environment.php file, from line 1476 to 1491, you can find:
```
		if ( $compression ) {
			$maybe_xml = '';
			if ($config->get_boolean('pgcache.cache.nginx_handle_xml')) {
				$maybe_xml = "\n" .
					"        text/xml xml_gzip\n" .
					"    ";
			}

			$rules .= "location ~ " . $cache_dir . ".*gzip$ {\n";
			$rules .= "    gzip off;\n";
			$rules .= "    types {" . $maybe_xml . "}\n";
			$rules .= "    default_type text/html;\n";
			$rules .= $common_rules;
			$rules .= "    add_header Content-Encoding gzip;\n";
			$rules .= "}\n";
		}
```
As you can see, the semicolon is missing in this line " text/xml xml_gzip\n" . (this should be " text/xml xml_gzip;\n" .)

Best regards,
- This reply was modified 8 years, 4 months ago by crewstyle.
Plugin Contributor gidomanders
(@gidomanders)

8 years, 3 months ago
I encountered the same problem. I have a development server built with docker and use Continuous Integration to deploy my project. Because the NginX service or the whole container are restarted pretty often, the wrong config is blocking all requests.

Because there is no reply nor any update that fixes this issue, I wrote a workaround to fix the NginX config file without changing the plugin code.
```
add_action('shutdown', function () {
    $filename = \W3TC\Util_Rule::get_pgcache_rules_cache_path();
    $contents = file_get_contents($filename);
    if (strpos($contents, "text/xml xml_gzip") !== false && strpos($contents, "text/xml xml_gzip;") === false) {
        file_put_contents($filename, str_replace('text/xml xml_gzip', 'text/xml xml_gzip;', $contents));
    }
});
```
This is a very bad one, but I couldn’t find any other filter or action to use. I tried a few, but the config got overwritten after my custom calls, so they didn’t work. If anyone knows what action or filter to use, please let me know!
Mateusz Owczarek
(@matowczarek)

8 years, 2 months ago

I encountered the problem too. It’s very annoying to have to check the Nginx configuration every time with sudo nginx -t, correct the error manually and then reload/restart the service.

This is a medium/high priority bug that should be fixed immediately, since it affects the entire Nginx configuration and if someone doesn’t check and fix the config and restarts Nginx, it will fail.

jezekjan
(@jezekjan)

8 years, 1 month ago

lack, that such a small bug is not solved after two months…
juslintek
(@juslintek)

8 years, 1 month ago
Yeah, same problem. I have W3 Total Cache Pro. Maybe I should contact them via the form maybe they will solve it faster.
- This reply was modified 8 years, 1 month ago by juslintek. Reason: Extra info
Mateusz Owczarek
(@matowczarek)

8 years ago

Fortunately, the problem is resolved in the 0.9.7 version.

Thread Starter crewstyle
(@crewstyle)

8 years ago

@mateusz: thanks for the news. But for me, that was too late: I switched to another plugin…
By the way, this bug is resolved.