A merge function is called whenever directives appear in more than one container in httpd.conf. It resolves conflicts between directives
in the various containers that may be applicable.
Normal behavior in the directory hierarchy meets the following criteria:
1. Any applicable <Directory> or <Location> overrides a configuration that isn't in any container.
2. A .htaccess file (if enabled) overrides httpd.conf for the same directory.
3. A directory's configuration overrides a parent directory's configuration.
4. Any applicable <Location> overrides <Files>, which overrides <Directory> and .htaccess.
5. The <Location> and <Files> containers overrides each other based not on specificity, but rather on the order in which they appear in httpd.conf.
6. Where configuration values are not explicitly set, they are inherited rather than overridden.
7. These relationships may be influenced by a module such as mod_alias hooking a relevant function before the map_to_storage phase.
Configuration functions can find out if they are in a <Limit> section by checking the "limited" field of the cmd_parms: It is set to -1
when nore in a <Limit> or <LimittExcept>, or to a bit field of <Limit>ed method numbers.
Alternatively, a directive may unconditionally refuse to work in a <Limit> by using ap_check_command_context with NOT_IN_LIMIT.
Modules more commonly want to know whether they are <Limit>ed later, when processing a request. At this point, there is an actual request,
and hence a method to check against the <Limit>.
In terms of its implementation, a container is simply an extended form of a directive. We can process its entire contents with AP_INIT_RAW_ARGS,
setting the EXEC_ON_READ flag to indicate that we will do something other than just passively consume the line.
In general, the provider API is well suited to supporting new classes of applications, in which implementing a provider will be the sole
or main purpose of a new module.
Unlike the API extensions we have looked at so far, the provider API works solely on a global lookup table. It doesn’t need to export
any function declarations, and in principle it might not need a header file at all, although in practice it is likely to export a declaration of
the provider structure it implements.
The key to the API is ap_lookup_provider. It can load dynamically a provider.
Transactions in apr_dbd correspond closely to SQL transactions. Transaction behavior depends on transaction mode, which is either APR_DBD_TRANSACTION_COMMIT
(the default) or APR_DBD_TRANSACTION_ROLLBACK; either of these modes can be ORed with APR_DBD_TRANSACTION_IGNORE
* When not in a transaction, all database operations are treated as in auto-commit-on-success mode.
* The transaction maintains a success-or-error state. If any database operation generates an error, the transaction is put into an error state.
* When the transaction is in an error state, no further database operations are performed while the transaction is in effect, and attempted operations will
immediately return with an error. APR_DBD_TRANSACTION_IGNORE
* When a transaction is ended, it will either COMMIT or ROLLBACK. If the transaction is in an error state or if APR_DBD_TRANSACTION_ROLLBACK is set, it will
ROLLBACK; otherwise, it will COMMIT. Within a transaction, nothing is committed or rolled back (unless you execute an SQL COMMIT or ROLLBACK using apr_dbd_query).
Some additional flags can be ORed with these log level values, the most interesting of which is APLOG_TOCLIENT. It is valid only in ap_log_rerror, and causes
the logger to set an entry in the request notes. Thus a handler can retrieve an error message using
errmsg = apr_table_get(r->notes, "error-notes");
and report the exact error message back to the browser. (Note that errmsg must be escaped if it appears in an HTML or XML response.)
To get a core dump, CoredumpDirectory directive in httpd.conf to somewhere the server apply the has permission to write, and ensure the operating system doesn't
prevent core ulimit).
in the various containers that may be applicable.
Normal behavior in the directory hierarchy meets the following criteria:
1. Any applicable <Directory> or <Location> overrides a configuration that isn't in any container.
2. A .htaccess file (if enabled) overrides httpd.conf for the same directory.
3. A directory's configuration overrides a parent directory's configuration.
4. Any applicable <Location> overrides <Files>, which overrides <Directory> and .htaccess.
5. The <Location> and <Files> containers overrides each other based not on specificity, but rather on the order in which they appear in httpd.conf.
6. Where configuration values are not explicitly set, they are inherited rather than overridden.
7. These relationships may be influenced by a module such as mod_alias hooking a relevant function before the map_to_storage phase.
Configuration functions can find out if they are in a <Limit> section by checking the "limited" field of the cmd_parms: It is set to -1
when nore in a <Limit> or <LimittExcept>, or to a bit field of <Limit>ed method numbers.
Alternatively, a directive may unconditionally refuse to work in a <Limit> by using ap_check_command_context with NOT_IN_LIMIT.
Modules more commonly want to know whether they are <Limit>ed later, when processing a request. At this point, there is an actual request,
and hence a method to check against the <Limit>.
In terms of its implementation, a container is simply an extended form of a directive. We can process its entire contents with AP_INIT_RAW_ARGS,
setting the EXEC_ON_READ flag to indicate that we will do something other than just passively consume the line.
In general, the provider API is well suited to supporting new classes of applications, in which implementing a provider will be the sole
or main purpose of a new module.
Unlike the API extensions we have looked at so far, the provider API works solely on a global lookup table. It doesn’t need to export
any function declarations, and in principle it might not need a header file at all, although in practice it is likely to export a declaration of
the provider structure it implements.
The key to the API is ap_lookup_provider. It can load dynamically a provider.
Transactions in apr_dbd correspond closely to SQL transactions. Transaction behavior depends on transaction mode, which is either APR_DBD_TRANSACTION_COMMIT
(the default) or APR_DBD_TRANSACTION_ROLLBACK; either of these modes can be ORed with APR_DBD_TRANSACTION_IGNORE
* When not in a transaction, all database operations are treated as in auto-commit-on-success mode.
* The transaction maintains a success-or-error state. If any database operation generates an error, the transaction is put into an error state.
* When the transaction is in an error state, no further database operations are performed while the transaction is in effect, and attempted operations will
immediately return with an error. APR_DBD_TRANSACTION_IGNORE
* When a transaction is ended, it will either COMMIT or ROLLBACK. If the transaction is in an error state or if APR_DBD_TRANSACTION_ROLLBACK is set, it will
ROLLBACK; otherwise, it will COMMIT. Within a transaction, nothing is committed or rolled back (unless you execute an SQL COMMIT or ROLLBACK using apr_dbd_query).
Some additional flags can be ORed with these log level values, the most interesting of which is APLOG_TOCLIENT. It is valid only in ap_log_rerror, and causes
the logger to set an entry in the request notes. Thus a handler can retrieve an error message using
errmsg = apr_table_get(r->notes, "error-notes");
and report the exact error message back to the browser. (Note that errmsg must be escaped if it appears in an HTML or XML response.)
To get a core dump, CoredumpDirectory directive in httpd.conf to somewhere the server apply the has permission to write, and ensure the operating system doesn't
prevent core ulimit).
扫一扫
1114
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
