Loading docs/manual/developer/layeredio.html +5 −5 Changes for docs/manual/developer/layeredio.html: 5 added lines, 5 removed lines. Original line number Diff line number Diff line Loading @@ -37,10 +37,10 @@ set the handler field to NULL, and allow the core to choose the which 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, Loading @@ -55,10 +55,10 @@ the same pipe. <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. Loading Loading
docs/manual/developer/layeredio.html +5 −5 Changes for docs/manual/developer/layeredio.html: 5 added lines, 5 removed lines. Original line number Diff line number Diff line Loading @@ -37,10 +37,10 @@ set the handler field to NULL, and allow the core to choose the which 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, Loading @@ -55,10 +55,10 @@ the same pipe. <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. Loading
