Ticket #2565 (assigned enhancement)
Apache module support for WMS
|Reported by:||aeichner||Owned by:||tbonfort|
|Cc:||mdsmith, dmorissette, springmeyer, assefa, jmckenna|
I mentioned in the thread "Hiding overviews" on the mapserver-users list that I've modified MapServer to run as Apache module. Due to several requests of interested people I file that first approach here. So before anyone goes patching, compiling and testing it some things should be noted.
Running directly as module has some advantages. For some people the most important reason is speed. Since you stay in one process there's no reason for forking and starting a new program and throwing away all the work you've done (all the things that could be cached) for every single request like the good old CGI does. You also don't need to move your data through pipes or the like to a dispatcher process which itself sends it back to Apache like the FastCGI does. Because the module should be bound to a specific URI serving exactly one map file (you may serve another map file by another URI) you need to load and parse the map file only once on startup which speeds up things a lot especially if you have large map files and use the INCLUDE directive excessively. Some other things have been mentioned in the "ModMapServer?" thread on the mapserver-users mailing list like simplified configuration.
I've created a module source which mostly consists of the loadMap() function from mapserv.c and a simple query string decoder (which does what cgiutil.c is normally responsible for). But it ignores the map= parameter and moves the map file loading into the startup code. A separate patch deals with the upcoming HTTP header problem. In CGI the headers, especially the "Content-Type" are send directly to the output stream while Apache wants it to be set in a field of it's request data structure. Basically I moved that in a macro and substituted the msIO_fprintf calls. So may be the macro should be moved to mapio.h and something like msIO_setContentType should be defined as that macro or simply the old msIO_fprintf depending whether we build as CGI or as module. The macro looks like happy hacking since we need access to the request_rec data structure and currently this is stored in the output handlers private context. That patch also modifies the configure.in and Makefile.in. And now it's time for a big fat warning: ONLY RUN IT WITH THE MPM PREFORK MODELL - MPM WORKER WILL CRASH DUE TO A RACE CONDITION Also, only the WMS portion has been modified and tested and can be used as an example. The other OGC parts may be done in much the same way, I believe. Ok, now you can go and try your luck. It has been successfully built and tested on the current 'testing' release of Debian GNU/Linux and on RedHat? Enterprise Linux 5 with additional packages from Fedora Core 6 (gdal, geos for example). Please also see the module source file. It is heavily commented and will probably help you understand what's done.