2e8e0e9f753e886f5ce93f4cfca91fc7 changes.txt

[packages/apache-mod_gzip.git] / changes.txt

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