Return to Guts_Apache.tex CVS log

Up to [LON-CAPA] / loncom / html / adm / help / tex

Annotation of loncom/html/adm/help/tex/Guts_Apache.tex, revision 1.2

1.2     ! albertel    1: \label{Guts_Apache}
        !             2: 
1.1       bowersj2    3: The standard mode in which the Apache web server is used is that a
                      4: URL corresponds to some static file on the file system, which then
                      5: more or less gets sent out as-is. Slight deviations from that simple
                      6: principle are however already the directory listing function, virtual
                      7: servers, and the cgi-bin directory. In the latter case, Apache executes
                      8: the file in a new process and provides both the input to the process
                      9: in the environment, and routes the output to the client. Other deviations
                     10: are the error messages.
                     11: 
                     12: In a more general view, URLs to Apache are URIs (Uniform Resource
                     13: Identifiers), which may are may not correspond to a physical file,
                     14: which in turn may or may not be sent out as-is.
                     15: 
                     16: As a request for a URI gets sent to the Apache server, it goes through
                     17: several phases. At each phase ({}``stage'') along the process, handler
                     18: modules can be defined to deal with the request. Details about these
                     19: phases are given in {}``Writing Apache Modules with Perl and C''
                     20: from O'Reilly (the {}``Eagle book'') in Chapter 3 (page 60).
                     21: 
                     22: These handler modules are not like cgi-scripts executed in a separate
                     23: process, but are dynamically linked into the Apache child processes
                     24: themselves - they run inside of Apache. The mod\_perl mechanism in
                     25: addition links the Perl interpreter into the Apache child process.
                     26: Modules are pre-interpreted ({}``compiled'') by the Perl interpreter
                     27: when they are first loaded, and the pre-interpreted code stays permanently
                     28: in the memory allocated to that Apache child process. The result is
                     29: a significant speed-up, and through the flexible mechanism of module
                     30: registration and different stages of the process, a high degree of
                     31: customizability.
                     32: 
                     33: LON-CAPA does \emph{not} use Apache::Registry, and so in addition
                     34: avoids the unnecessary overhead of emulating a cgi-environment within
                     35: the handlers. Instead, it makes direct use of the Apache Perl API
                     36: (Chapter 9, Eagle book).
                     37: 
                     38: If you intend to add new capabilities to LON-CAPA that require new
                     39: handlers, as opposed to tweaking current ones, we recommend buying
                     40: a copy of {}``Writing Apache Modules with Perl and C''; it is not
                     41: strictly necessary but it is the clearest description of what is going
                     42: on in the Apache server, and without it you will be challenged to
                     43: understand everything that is occurring in the server.