2e8e0e9f753e886f5ce93f4cfca91fc7 changes.txt

Changed files:
    changes.txt -> 1.1

diff --git a/changes.txt b/changes.txt
new file mode 100644 (file)
index 0000000..9dc4335
--- /dev/null
+++ b/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
+
+
+