changes.txt

   1
   2 CHANGES in Version 1.3.19.1a
   3
   4 * mod_gzip_can_negotiate Yes
   5
   6 This new httpd.conf directive is probably the most
   7 important new feature.
   8
   9 If 'mod_gzip_can_negotiate' command is set to 'Yes'
  10 then mod_gzip will essentially 'take over' some of
  11 the duties of mod_negotiate and will automatically
  12 check for static pre-existing compressed versions
  13 of requested file(s).
  14
  15 In other words... if the user requests 'filename.html'
  16 and there happens to already be a pre-compressed
  17 version of that page named 'filename.html.gz' then
  18 mod_gzip will immediately return the pre-compressed
  19 version rather than perform a dynamic compression
  20 of the file.
  21
  22 The delivery of the pre-compressed version of the file
  23 is still subject to the same 'rules' that govern the
  24 delivery of compressed data to a user-agent. The user-agent
  25 must have indicated it is capable of receiving compressed
  26 content and the file/mime type itself must be one of the
  27 valid mod_gzip 'inclusion' items specified using the
  28 normal mod_gzip_item_include/exclude statements.
  29
  30 The 'mod_negotiate' module for Apache does not currently
  31 have the 'smarts' that mod_gzip does with regards to
  32 evaluating user-agents and inbound request headers and while it
  33 is (sometimes) able to 'negotiate' for static compressed versions
  34 of files it does not have anything comparable to the safety checks
  35 or the include/exclude item filtering logic that mod_gzip has.
  36
  37 It is much 'safer' to set the 'mod_gzip_can_negotiate'
  38 flag to 'Yes' and let mod_gzip check for ( and deliver )
  39 static compressed versions of files than it is to let
  40 mod_negotiate make the same decisions.
  41
  42 If mod_gzip finds a pre-compressed version of a requested
  43 file and all the filtering and safety checks allow that
  44 static compressed version to be delivered back to the
  45 client then the mod_gzip 'result' string in the access.log
  46 file will be...
  47
  48 mod_gzip: DECLINED:STATIC_GZ_FOUND
  49
  50 In this case... 'DECLINED' does not mean that no compressed
  51 data was returned. It means that mod_gzip has screened the
  52 request according to its filtering logic and has concluded
  53 that is is OK for Apache itself to flow the pre-compressed
  54 version back to the user-agent. 'DECLINED' means it was
  55 not 'dynamically' compressed and 'STATIC_GZ_FOUND' means
  56 a pre-compressed version was returned to the user-agent.
  57
  58 In the cases where a user-agent has specifically requested
  59 a filename.html.gz file then the result string will be...
  60
  61 mod_gzip: DECLINED:FEXT_GZ
  62
  63 Which means that mod_gzip simply 'passed' on the transaction.
  64
  65
  66 * 'mod_gzip_command_version' directive has returned.
  67
  68 The mod_gzip 'command' interface is back but now it
  69 has a different 'twist'. For security reasons you must
  70 now specify yourself what the 'command' is for certain
  71 functions like 'Get version'.
  72
  73 This way... only you will know what the command is so
  74 you can test your own site(s). The command(s) can be
  75 different strings for each Virtual Host, if desired.
  76
  77 To enable mod_gzip to do the 'version' command just
  78 add this to your httpd.conf file...
  79
  80 mod_gzip_command_version mod_gzip_show_version
  81
  82 The 'mod_gzip_show_version' string can be anything you
  83 like and this is the 'command' that you can now send
  84 to your server to have it respond with mod_gzip version
  85 information as an HTML response page.
  86
  87 Example: Using the above command definition all you have
  88 to do to get the Server to provide the mod_gzip version
  89 information ( and whether or not mod_gzip is enabled
  90 for that location ) is type this into your browser...
  91
  92 http://www.your_server_name.com/mod_gzip_show_version
  93
  94 If you have added the 'mod_gzip_command_version' config
  95 parameter to 'your_server_name' httpd.conf file then
  96 you will not get a '404 File not found'... you will get this...
  97
  98 mod_gzip is available on this Server...
  99 mod_gzip_version = 1.3.19.1a
 100 mod_gzip_on = Yes
 101
 102 If mod_gzip is installed but is not 'on' for whatever
 103 location is requested ( based on Virtual Server name )
 104 then this will also be indicated with 'mod_gzip_on = No'
 105 in the response.
 106
 107 This is a good way to tell 3 things...
 108
 109 1. Is mod_gzip installed and functioning correctly.
 110 2. What version is it?
 111 3. Is mod_gzip turned 'on' for the requested 'location' (Server)?
 112
 113 The command interface will check the entire URI for the
 114 command pickup string so, if you desire, you can do this
 115 as well...
 116
 117 http://www.your_server_name.com/dummypage.html?mod_gzip_show_version
 118
 119 The command string does not have to be part of the URI filename
 120 and can be included as a query parm following any filename.
 121 You will not receive the file... you will get the mod_gzip
 122 command result page instead.
 123
 124 This might work better for some who want to add the 'command'
 125 link to existing pages since, if mod_gzip is not installed
 126 on 'your_server_name', Apache will still try to locate and
 127 return the page called 'dummypage.html' which might be better
 128 for some scenarios than a '404 Not found' response.
 129
 130
 131 * New 'uri' include/exclude record type added...
 132
 133 The existing 'type' names for inclusion/exclusion should
 134 be adequate for just about anything but one or two
 135 scenarios involving complicated uses of 'ScriptAlias'
 136 have surfaced which could probably benefit from doing
 137 a keyword lookup on the URI itself and not the filename
 138 or mime type.
 139
 140 To that end there is now a new 'type' name that can used...
 141
 142 mod_gzip_item_include uri .*foo.*
 143
 144 This will cause all requests for URIs with the characters 'foo'
 145 in it to be 'included'.
 146
 147 NOTE: You can use either 'uri' or 'url' as the record type name.
 148
 149 Using the 'file' pickup type is still the best ( and most accurate )
 150 thing to do so using the new 'uri' pickup is 'swim at your own risk'.
 151 It should work fine if used properly.
 152
 153
 154 * In-memory compression option is back on.
 155
 156 The 'in-memory' compression option which was temporarily
 157 disabled in the prior version is now back on. The
 158 'mod_gzip_maximum_inmem_size xxxx' config parameter is
 159 what sets the maximum size of a source object ( in bytes )
 160 that can/will be compressed completely in memory.
 161
 162 If the 'mod_gzip_maximum_inmem_size' value is either
 163 ZERO or not specified then the 'in-memory' compression
 164 option is effectively disabled and will not be used.
 165
 166 Due to one remaining problem with some OS'es being unable
 167 to use allocations greater than 64k the maximum value
 168 is limited to 60,000 bytes ( allowing for some overspill ).
 169
 170 60,000 bytes is perfectly adequate for most responses.
 171 Anything larger than that probably SHOULD use a workfile.
 172
 173 Next version will allow any size to be used but be forewarned
 174 that testing has already shown that on a busy Server anything
 175 over 60k should probably not use the 'in-memory' option anyway
 176 since a busy Server needs all the memory it can get spread across
 177 hundreds of transactions per second to keep the performance up.
 178
 179
 180 * mod_gzip_item_include/exclude description updated.
 181
 182 Used to report...
 183 ARG1=[mime,file,handler,agent]
 184
 185 Now correctly reports...
 186 ARG1=[mime,file,uri,handler,reqheader,rspheader]
 187
 188
 189 END OF FILE
 190
 191
 192