module gets run next. If these two fields are not modified, then the server
will loop forever calling the same module's handler.
-<P>Most module's should not write out to the network if they want to take
+<P>Most modules should not write out to the network if they want to take
advantage of layered I/O. Two BUFF structures have been added to the
-request_rec, one of input, and one for output. The module should read and
-write to these BUFF's. The module will also have to setup the input field for
+request_rec, one for input and one for output. The module should read and
+write to these BUFFs. The module will also have to setup the input field for
the next module in the list. A new function has been added, ap_setup_input,
which all modules should call before they do any reading to get data to modify.
This function checks to determine if the previous module set the input field,
<H3>An Example of Layered I/O.</H3>
<P>This example is the most basic layered I/O example possible. It is
-basically CGI's generated by mod_cgi and sent to the network via http_core.
+basically CGIs generated by mod_cgi and sent to the network via http_core.
<P>mod_cgi executes the cgi script, and then sets request_rec->input to
-the output pipe of the CGI. It then NULL's out request_rec->handler, and
+the output pipe of the CGI. It then NULLs out request_rec->handler, and
sets request_rec->content_type to whatever the CGI writes out (in this case,
text/html). Finally, mod_cgi returns RERUN_HANDLERS.