CHANGES in Version 1.3.19.1a * mod_gzip_can_negotiate Yes This new httpd.conf directive is probably the most important new feature. If 'mod_gzip_can_negotiate' command is set to 'Yes' then mod_gzip will essentially 'take over' some of the duties of mod_negotiate and will automatically check for static pre-existing compressed versions of requested file(s). In other words... if the user requests 'filename.html' and there happens to already be a pre-compressed version of that page named 'filename.html.gz' then mod_gzip will immediately return the pre-compressed version rather than perform a dynamic compression of the file. The delivery of the pre-compressed version of the file is still subject to the same 'rules' that govern the delivery of compressed data to a user-agent. The user-agent must have indicated it is capable of receiving compressed content and the file/mime type itself must be one of the valid mod_gzip 'inclusion' items specified using the normal mod_gzip_item_include/exclude statements. The 'mod_negotiate' module for Apache does not currently have the 'smarts' that mod_gzip does with regards to evaluating user-agents and inbound request headers and while it is (sometimes) able to 'negotiate' for static compressed versions of files it does not have anything comparable to the safety checks or the include/exclude item filtering logic that mod_gzip has. It is much 'safer' to set the 'mod_gzip_can_negotiate' flag to 'Yes' and let mod_gzip check for ( and deliver ) static compressed versions of files than it is to let mod_negotiate make the same decisions. If mod_gzip finds a pre-compressed version of a requested file and all the filtering and safety checks allow that static compressed version to be delivered back to the client then the mod_gzip 'result' string in the access.log file will be... mod_gzip: DECLINED:STATIC_GZ_FOUND In this case... 'DECLINED' does not mean that no compressed data was returned. It means that mod_gzip has screened the request according to its filtering logic and has concluded that is is OK for Apache itself to flow the pre-compressed version back to the user-agent. 'DECLINED' means it was not 'dynamically' compressed and 'STATIC_GZ_FOUND' means a pre-compressed version was returned to the user-agent. In the cases where a user-agent has specifically requested a filename.html.gz file then the result string will be... mod_gzip: DECLINED:FEXT_GZ Which means that mod_gzip simply 'passed' on the transaction. * 'mod_gzip_command_version' directive has returned. The mod_gzip 'command' interface is back but now it has a different 'twist'. For security reasons you must now specify yourself what the 'command' is for certain functions like 'Get version'. This way... only you will know what the command is so you can test your own site(s). The command(s) can be different strings for each Virtual Host, if desired. To enable mod_gzip to do the 'version' command just add this to your httpd.conf file... mod_gzip_command_version mod_gzip_show_version The 'mod_gzip_show_version' string can be anything you like and this is the 'command' that you can now send to your server to have it respond with mod_gzip version information as an HTML response page. Example: Using the above command definition all you have to do to get the Server to provide the mod_gzip version information ( and whether or not mod_gzip is enabled for that location ) is type this into your browser... http://www.your_server_name.com/mod_gzip_show_version If you have added the 'mod_gzip_command_version' config parameter to 'your_server_name' httpd.conf file then you will not get a '404 File not found'... you will get this... mod_gzip is available on this Server... mod_gzip_version = 1.3.19.1a mod_gzip_on = Yes If mod_gzip is installed but is not 'on' for whatever location is requested ( based on Virtual Server name ) then this will also be indicated with 'mod_gzip_on = No' in the response. This is a good way to tell 3 things... 1. Is mod_gzip installed and functioning correctly. 2. What version is it? 3. Is mod_gzip turned 'on' for the requested 'location' (Server)? The command interface will check the entire URI for the command pickup string so, if you desire, you can do this as well... http://www.your_server_name.com/dummypage.html?mod_gzip_show_version The command string does not have to be part of the URI filename and can be included as a query parm following any filename. You will not receive the file... you will get the mod_gzip command result page instead. This might work better for some who want to add the 'command' link to existing pages since, if mod_gzip is not installed on 'your_server_name', Apache will still try to locate and return the page called 'dummypage.html' which might be better for some scenarios than a '404 Not found' response. * New 'uri' include/exclude record type added... The existing 'type' names for inclusion/exclusion should be adequate for just about anything but one or two scenarios involving complicated uses of 'ScriptAlias' have surfaced which could probably benefit from doing a keyword lookup on the URI itself and not the filename or mime type. To that end there is now a new 'type' name that can used... mod_gzip_item_include uri .*foo.* This will cause all requests for URIs with the characters 'foo' in it to be 'included'. NOTE: You can use either 'uri' or 'url' as the record type name. Using the 'file' pickup type is still the best ( and most accurate ) thing to do so using the new 'uri' pickup is 'swim at your own risk'. It should work fine if used properly. * In-memory compression option is back on. The 'in-memory' compression option which was temporarily disabled in the prior version is now back on. The 'mod_gzip_maximum_inmem_size xxxx' config parameter is what sets the maximum size of a source object ( in bytes ) that can/will be compressed completely in memory. If the 'mod_gzip_maximum_inmem_size' value is either ZERO or not specified then the 'in-memory' compression option is effectively disabled and will not be used. Due to one remaining problem with some OS'es being unable to use allocations greater than 64k the maximum value is limited to 60,000 bytes ( allowing for some overspill ). 60,000 bytes is perfectly adequate for most responses. Anything larger than that probably SHOULD use a workfile. Next version will allow any size to be used but be forewarned that testing has already shown that on a busy Server anything over 60k should probably not use the 'in-memory' option anyway since a busy Server needs all the memory it can get spread across hundreds of transactions per second to keep the performance up. * mod_gzip_item_include/exclude description updated. Used to report... ARG1=[mime,file,handler,agent] Now correctly reports... ARG1=[mime,file,uri,handler,reqheader,rspheader] END OF FILE
