general/2703: MODULE_MAGIC_NUMBER checking makes distributing modules in binary form nearly impossible

[William Bardwell <wb...@platinum.com>]

>Number:         2703
>Category:       general
>Synopsis:       MODULE_MAGIC_NUMBER checking makes distributing modules in binary form nearly impossible
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    apache
>State:          open
>Class:          change-request
>Submitter-Id:   apache
>Arrival-Date:   Fri Jul 24 11:10:03 PDT 1998
>Last-Modified:
>Originator:     wbardwel@platinum.com
>Organization:
apache
>Release:        1.3.X
>Environment:
All
>Description:
The manner in which Apache barfs if a module doesn't have the exact same
MODULE_MAGIC_NUMBER as the server itself makes distributing modules as binaries
very combersome, since you have to provide a binary for every possible revision
of Apache (or atleast have a struct module for each one).  With the new DSO
stuff the idea of distributing modules as binaries would otherwise be very
attractive.  (Also, this checking means that if you send someone a module as
a binary, they can't upgrade their version of Apache till you send them a new
version of your binary, for the new version of Apache.)
>How-To-Repeat:

>Fix:
One of two things:
1) change the magic number checking so it would only reject a module if it was for
a totally different version of apache (ie all 1.3.X would take a module built for
1.3...)
2) make a special magic number that module writers, who would like to, can use
to tell Apache not to worry about what version they are (and Apache would not
complain if it sees that one.)  (You could still leave STANDARD_MODULE_STUFF
using the current system.)
3) combination of both (ie special magic number values that do #1, but default
is same as now...)
>Audit-Trail:
>Unformatted:
[In order for any reply to be added to the PR database, ]
[you need to include <ap...@Apache.Org> in the Cc line ]
[and leave the subject line UNCHANGED.  This is not done]
[automatically because of the potential for mail loops. ]