diff options
Diffstat (limited to 'net-www/mod_gzip/files/changes.txt')
| -rw-r--r-- | net-www/mod_gzip/files/changes.txt | 192 |
1 files changed, 192 insertions, 0 deletions
diff --git a/net-www/mod_gzip/files/changes.txt b/net-www/mod_gzip/files/changes.txt new file mode 100644 index 000000000000..9dc4335950d7 --- /dev/null +++ b/net-www/mod_gzip/files/changes.txt @@ -0,0 +1,192 @@ + +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 + + + |