httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [SUBMIT] mod_gzip 2.0.26a ( Non-debug version )
Date Sun, 16 Sep 2001 06:02:40 GMT
In a message dated 01-09-16 04:31:56 EDT, justin writes...

> - For Ian's mod_gz, I removed the dependency on zutil.h as it is static
>    and OS_CODE seems to defined as part of the RFC (I may be wrong here).

>    Most installations do not include zutil.h in their install (such as
>    Solaris), so we can't expect it to be there.  This *may* require 
>    adding the zlib license for those chunk of lines.  It seems to be a flaw 
>    in zlib that they require an internal definition for actual use.

There is no reference to ZUTIL.H in ZLIB.H or ZCONF.H which are
in most standard binary distributions of ZLIB.

It's only if you use the manifest constant when building the header
will you get a 'symbol not defined' error.

Actually... since you are only compressing you could probably just
dump this one default catch-all from ZUTIL itself right into whatever
code you are using.

#ifndef OS_CODE
#  define OS_CODE  0x03  /* assume Unix */

Question would be if it affects the inflate() calls in the user agents.
I doubt it. Haven't personally tested 'faking' the OS_CODE.

>  - I dunno what the _set variables are either.  Do we need them?

It's a tried and true way of making it easier to 'merge' 2 module
configurations and make a distinction between true 'default' 
values and values that might have been set by actual configuration
commands. Goes all the way back to original 1.x modules.

It's an easy way to have 'default' values for a Location/Server 
config other than ZERO or NULL and be able to know if a
value was actually 'set' by a prior config command or whether
the default is still in effect.

Example: When a new Server/Location configuratin is created
the default LZ77 deflate() compression level is 6. Unless a
specific 'mod_gzip_compression_level' was given in a directory
or Virtual Host section then it remains the non-zero default.

When merging... either you have to compare against the
same manifest constant to know which value to use or just
check a '_set' flag which tells you if the value was truly 'set'
by a configuration directive or not.

If you write a lot of modules it just sort of becomes a habit.

>  - The str* funcs are thread-safe on any platform we care about.
>    If the libc implementations aren't thread-safe, there are other
>    problems that we'll have in the core that mod_gzip's thread-safety
>    will be the least of our problems.

As I mentioned... those calls only became necessary when we
ported to some platforms that not only don't have 'strxxx' calls,
there isn't even a STDLIB to use ( Win32 on HP Jornada, etc. ).

Probably not an issue for you guys.

>  - npp isn't completely bogus - I did essentially the same thing in
>    flood.  I did:
>      r->uri ? r->uri : ""
>    instead.  No need for a separate function though.

Really only needed for Solaris, as the comments indicate.
AFAIK only Solaris has a bad habit of puking on null pointer
>  - I think the IMAP_* stuff can be handled better by the filter directive
>    syntax.  Ideally, mod_gz{ip} would be configured as a filter for
>    certain mime types or extensions.  Not sure we need to complicate things 
>    by allowing inclusion/exclusion via other config syntaxes.

See previous mention of cross-header inclusion/exlusion references
which became becessary after people really started using
dynamic compression in the 'real world'. Also see many messages
about this on the mod_gzip forum.

Not sure how you can do the cross-header inclusion/exclusion
by just focusing on mime/file types. It's more complicated than that.
>  - I don't understand why we need do_command.

The original version(s) of mod_gzip had complete built-in 
real-time compression statistics screens that any admin
could 'call up' using all kinds of URL based commands.

Sort of a built-in admin interface.

The 'mod_gzip_version' command was the only one that was
kept because current mod_gzip users all said they were 
depending on it to be there.

Keep it or not, it's up to you.
>  - I don't think we need the eligibility checks either.  The mod_mime
>    and core should handle this.

See above or see the mod_gzip forum.
I believe it's a little more complicated than you think.

The 'checks' could most certainly be in 'type_checker' or 'mime'
hooks in the module itself, as they are in mod_gzip 1.3.x version(s)
but it involves more than just file extension or mime type.
>  - I don't think we need the handler either.

Are you talking about the eligibility check for 'handler' type
or the module's mod_gzip_handler( ) routine itself ?

I believe you will find that both are needed in the long run.
Again... see the mod_gzip forum.

Kevin Kiley

View raw message