stas 2002/09/01 20:38:50
Modified: src/docs/2.0/user/config config.pod
src/docs/2.0/user/handlers handlers.pod
Log:
speling
Revision Changes Path
1.22 +14 -46 modperl-docs/src/docs/2.0/user/config/config.pod
Index: config.pod
===================================================================
RCS file: /home/cvs/modperl-docs/src/docs/2.0/user/config/config.pod,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- config.pod 13 Aug 2002 11:41:45 -0000 1.21
+++ config.pod 2 Sep 2002 03:38:50 -0000 1.22
@@ -6,7 +6,7 @@
=head1 Description
-This chapter provides an indepth mod_perl 2.0 configuration details.
+This chapter provides an in-depth mod_perl 2.0 configuration details.
@@ -120,7 +120,7 @@
use Apache::compat ();
-Next we preload the commanly used mod_perl 2.0 modules and precompile
+Next we preload the commonly used mod_perl 2.0 modules and precompile
common constants.
Finally as usual the I<startup.pl> file must be terminated with C<1;>.
@@ -213,8 +213,8 @@
$r->dir_config('VarTest');
Alternatively use the Apache core directives C<SetEnv> and C<PassEnv>,
-which always populate C<r-E<gt>suprocess_env>, but this doesn't happen
-until the Apache fixup phase, which could be too late for your needs.
+which always populate C<r-E<gt>subprocess_env>, but this doesn't happen
+until the Apache I<fixups> phase, which could be too late for your needs.
=head2 perl-script
@@ -431,7 +431,7 @@
=head2 C<ParseHeaders>
Scan output for HTTP headers, same functionality as mod_perl 1.0's
-C<PerlSendHeaders>, but more robust. This option is usually needs to
+C<PerlSendHeader>, but more robust. This option is usually needs to
be enabled for registry scripts which send the HTTP header with:
print "Content-type: text/html\n\n";
@@ -462,7 +462,7 @@
=head2 C<SetupEnv>
-Set up enviroment variables for each request ala mod_cgi.
+Set up environment variables for each request ala mod_cgi.
When this option is enabled, I<mod_perl> fiddles with the environment
to make it appear as if the code is called under the mod_cgi handler.
@@ -563,7 +563,7 @@
=head2 C<PerlInterpStart>
-The number of intepreters to clone at startup time.
+The number of interpreters to clone at startup time.
=head2 C<PerlInterpMax>
@@ -604,8 +604,8 @@
will be selected before it is run and not released until after the
logging phase.
-Intepreters will be shared across subrequests by default, however, it
-is possible to configure the intepreter scope to be per-subrequest on
+Interpreters will be shared across sub-requests by default, however, it
+is possible to configure the interpreter scope to be per-sub-request on
a per-directory basis:
PerlInterpScope subrequest
@@ -619,10 +619,10 @@
PerlInterpScope handler
With this configuration, an interpreter will be selected before
-C<PerlAccessHandlers> are run, and putback immediately afterwards,
+C<PerlAccessHandlers> are run, and put back immediately afterwards,
before Apache moves onto the authentication phase. If a
C<PerlFixupHandler> is configured further down the chain, another
-interpreter will be selected and again putback afterwards, before
+interpreter will be selected and again put back afterwards, before
C<PerlResponseHandler> is run.
For protocol handlers, the interpreter is held for the lifetime of the
@@ -756,7 +756,7 @@
=item DIR
C<E<lt>DirectoryE<gt>>, C<E<lt>LocationE<gt>>, C<E<lt>FilesE<gt>> and
-all their regex variants (mnemonic: I<DIRectory>). These directives
+all their regular expression variants (mnemonic: I<DIRectory>). These
directives
can also appear in I<.htaccess> files. These directives are defined
as C<OR_ALL> in the source code.
@@ -769,40 +769,8 @@
used by the core mod_perl directives and their definition can be found
in I<include/httpd_config.h> (hint: search for C<RSRC_CONF>).
-
-The I<Type> column specifies a phase's behavior when there is more
-then one handler registered to run for this phase. (For C API
-declarations see I<include/ap_config.h>, which includes other types
-which aren't exposed by mod_perl.)
-
-
-=over
-
-=item * VOID
-
-Handlers of the type C<VOID> will be I<all> executed in the order they
-have been registered disregarding their return values. Though in
-mod_perl they are expected to return C<Apache::OK>.
-
-=item * RUN_FIRST
-
-Handlers of the type C<RUN_FIRST> will be executed in the order they
-have been registered until the first handler that returns something
-other than C<Apache::DECLINED>. If the return value is
-C<Apache::DECLINED>, the next handler in the chain will be run. If the
-return value is C<Apache::OK> the next phase will start. In all other
-cases the execution will be aborted.
-
-=item * RUN_ALL
-
-Handlers of the type C<RUN_ALL> will be executed in the order they
-have been registered until the first handler that returns something
-other than C<Apache::OK> or C<Apache::DECLINED>.
-
-=back
-
-Also see L<mod_perl Directives Argument Types and Allowed
-Location|user::config::config/mod_perl_Directives_Argument_Types_and_Allowed_Location>
+Also see L<Perl*Handler
+Types|docs::2.0::user::handlers::handlers/Perl_Handler_Types>.
1.20 +16 -16 modperl-docs/src/docs/2.0/user/handlers/handlers.pod
Index: handlers.pod
===================================================================
RCS file: /home/cvs/modperl-docs/src/docs/2.0/user/handlers/handlers.pod,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- handlers.pod 30 Aug 2002 18:26:00 -0000 1.19
+++ handlers.pod 2 Sep 2002 03:38:50 -0000 1.20
@@ -12,7 +12,7 @@
Apache distinguish between numerous phases for which it provides hooks
(because the C functions are called I<ap_hook_E<lt>phase_nameE<gt>>)
where modules can plug various callbacks to extend and alter the
-default behaviour of the webserver. mod_perl provides a Perl
+default behavior of the webserver. mod_perl provides a Perl
interface for most of the available hooks, so mod_perl modules writers
can change the Apache behavior in Perl. These callbacks are usually
referred to as I<handlers> and therefore the configuration directives
@@ -189,7 +189,7 @@
First of all, we can clearly see that Apache always restart itself
after the first I<post_config> phase is over. The logs show that the
-I<post_config> phase is preceeded by the I<open_logs> phase. Only
+I<post_config> phase is preceded by the I<open_logs> phase. Only
after Apache has restarted itself and has completed the I<open_logs>
and I<post_config> phase again the I<child_init> phase is run for each
child process. In our example we have had the setting
@@ -359,7 +359,7 @@
blocks, end of stream indicators, pools, etc. To manipulate a bucket
one doesn't need to know its internal representation.
-The stream of data is represented by bucket bridades. When a filter
+The stream of data is represented by bucket brigades. When a filter
is called it gets passed the brigade that was the output of the
previous filter. This brigade is then manipulated by the filter (e.g.,
by modifying some buckets) and passed to the next filter in the stack.
@@ -734,8 +734,8 @@
pass_brigade($bb_out);
}
-The handler receives the incoming data via bucket bridages, one at a
-time in a loop. It then process each bridage, by retrieving the
+The handler receives the incoming data via bucket bridges, one at a
+time in a loop. It then process each bridge, by retrieving the
buckets contained in it, reading the data in, then creating new
buckets using the received data, and attaching them to the outgoing
brigade. When all the buckets from the incoming bucket brigade were
@@ -823,7 +823,7 @@
phases terminates it, usually when an error happens.
Notice that when the response handler is reading the input data it can
-be filtered through request input filters, which are preceeded by
+be filtered through request input filters, which are preceded by
connection input filters if any. Similarly the generated response is
first run through request output filters and eventually through
connection output filters before it's sent to the client. We will talk
@@ -837,7 +837,7 @@
immediately after the request has been read and HTTP headers were
parsed.
-This phase is usually used to do processings that must happen once per
+This phase is usually used to do processing that must happen once per
request. For example C<Apache::Reload> is usually invoked at this
phase to reload modified Perl modules.
@@ -951,7 +951,7 @@
There are many useful things that can be performed at this
stage. Let's look at the example handler that rewrites request URIs,
-similar to what mod_rewrite does. For example, if your website was
+similar to what mod_rewrite does. For example, if your web-site was
originally made of static pages, and now you have moved to a dynamic
page generation chances are that you don't want to change the old
URIs, because you don't want to break links for those who link to your
@@ -1011,7 +1011,7 @@
request has been mapped to its C<E<lt>LocationE<gt>> (or an equivalent
container). At this phase the handler can examine the request headers
and to take a special action based on these. For example this phase
-can be used to block evil clients targetting certain resources, while
+can be used to block evil clients targeting certain resources, while
little resources were wasted so far.
This phase is of type C<L<RUN_ALL|/item_RUN_ALL>>.
@@ -1027,10 +1027,10 @@
C<L<PerlPostReadRequestHandler|/PerlPostReadRequestHandler>> and turn
it into C<L<PerlHeaderParserHandler|/PerlHeaderParserHandler>> by
simply changing the directive name in I<httpd.conf> and moving it
-inside the contrainer where it should be executed. Moreover, because
+inside the container where it should be executed. Moreover, because
of this similarity mod_perl provides a special directive
C<L<PerlInitHandler|/PerlInitHandler>> which if found outside resource
-countainers behaves as
+containers behaves as
C<L<PerlPostReadRequestHandler|/PerlPostReadRequestHandler>>,
otherwise as C<L<PerlHeaderParserHandler|/PerlHeaderParserHandler>>.
@@ -1038,7 +1038,7 @@
several other HTTP methods. But did you know that you can invent your
own HTTP method as long as there is a client that supports it. If you
think of emails, they are very similar to HTTP messages: they have a
-set of headers and a body, sometimes a multipart body. Therefore we
+set of headers and a body, sometimes a multi-part body. Therefore we
can develop a handler that extends HTTP by adding a support for the
C<EMAIL> method. We can enable this protocol extension during and
push the real content handler during the
@@ -1386,7 +1386,7 @@
algorithm is unusual. Instead of validating the username/password pair
against a password file, we simply check that the string built from
these two items plus a single space is C<SECRET_LENGTH> long (14 in
-our example). So for example the pair I<mod_perl/rules> autheniticates
+our example). So for example the pair I<mod_perl/rules> authenticates
correctly, whereas I<secret/password> does not, because the latter
pair will make a string of 15 characters. Of course this is not a
strong authentication scheme and you shouldn't use it for serious
@@ -1772,7 +1772,7 @@
The I<log_transaction> phase happens no matter how the previous phases
have ended up. If one of the earlier phases has aborted a request,
-e.g., failed authenication or 404 (file not found) errors, the rest of
+e.g., failed authentication or 404 (file not found) errors, the rest of
the phases up to and including the response phases are skipped. But
this phase is always executed.
@@ -2201,7 +2201,7 @@
right away. After that we pass the brigade to the next filter.
Finally we dump to STDERR the information about the type of the
-current mode, and the content of the bucket bridage.
+current mode, and the content of the bucket bridge.
Let's snoop on connection and request filter levels in both
directions by applying the following configuration:
@@ -2453,7 +2453,7 @@
modifies the data, creates a new bucket using the modified data and
links it to the tail of the outgoing brigade, while discarding the
original bucket. In our case the interesting data is a such that
-matches the regex C</^GET/>. If the data is not interesting to the
+matches the regular expression C</^GET/>. If the data is not interesting to
the
handler, it simply links the unmodified bucket to the outgoing
brigade.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
