>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: [EMAIL PROTECTED] >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 <[EMAIL PROTECTED]> in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ]
