Filter Objects
The filter object is defined in util_filter.h.
/**
* The representation of a filter chain. Each request has a list
* of these structures, which are called in turn to filter the data.
* Subrequests get an exact copy of the main request's filter chain.
*/
struct ap_filter_t {
/** The internal representation of this filter. This includes
* the filter's name, type, and the actual function pointer.
*/
ap_filter_rec_t *frec;
/** A place to store any data associated with the current filter */
void *ctx;
/** The next filter in the chain */
ap_filter_t *next;
/** The request_rec associated with the current filter. If a subrequest
* adds filters, then the subrequest is the request associated with the
* filter.
*/
request_rec *r;
/** The conn_rec associated with the current filter. This is analogous
*to the request_rec, except that it is used for connection filters.
*/
conn_rec *c;
};
The field ctx will use to store application data for the filter between calls, and request_rec, to access all
the normal request data. (In the case of connection-level filters, there is no valid request_rec field, and the
conn_rec serves a similar purpose.)
/**
* This structure is used for recording information about the
* registered filters. It associates a name with the filter's callback
* and filter type.
*
* At the moment, these are simply linked in a chain, so a ->next pointer
* is available.
*
* It is used for any filter that can be inserted in the filter chain.
* This may be either an httpd-2.0 filter or a mod_filter harness.
* In the latter case, it contains provider and protocol information.
* In the former case, the new fields (from providers) are ignored.
*/
struct ap_filter_rec_t {
/** The registered name for this filter */
const char *name;
/** The function to call when this filter is invoked. */
ap_filter_func filter_func;
/** The function to call before the handlers are invoked. Notice
* that this function is called only for filters participating in
* the HTTP protocol. Filters for other protocols are to be
* initialized by the protocols themselves.
*/
ap_init_filter_func filter_init_func;
/** The type of filter, either AP_FTYPE_CONTENT or AP_FTYPE_CONNECTION.
* An AP_FTYPE_CONTENT filter modifies the data based on information
* found in the content. An AP_FTYPE_CONNECTION filter modifies the
* data based on the type of connection.
*/
ap_filter_type ftype;
/** The next filter_rec in the list */
struct ap_filter_rec_t *next;
/** Providers for this filter */
ap_filter_provider_t *providers;
/** Trace level for this filter */
int debug;
/** Protocol flags for this filter */
unsigned int proto_flags;
};
The filter object is defined in util_filter.h.
/**
* The representation of a filter chain. Each request has a list
* of these structures, which are called in turn to filter the data.
* Subrequests get an exact copy of the main request's filter chain.
*/
struct ap_filter_t {
/** The internal representation of this filter. This includes
* the filter's name, type, and the actual function pointer.
*/
ap_filter_rec_t *frec;
/** A place to store any data associated with the current filter */
void *ctx;
/** The next filter in the chain */
ap_filter_t *next;
/** The request_rec associated with the current filter. If a subrequest
* adds filters, then the subrequest is the request associated with the
* filter.
*/
request_rec *r;
/** The conn_rec associated with the current filter. This is analogous
*to the request_rec, except that it is used for connection filters.
*/
conn_rec *c;
};
The field ctx will use to store application data for the filter between calls, and request_rec, to access all
the normal request data. (In the case of connection-level filters, there is no valid request_rec field, and the
conn_rec serves a similar purpose.)
/**
* This structure is used for recording information about the
* registered filters. It associates a name with the filter's callback
* and filter type.
*
* At the moment, these are simply linked in a chain, so a ->next pointer
* is available.
*
* It is used for any filter that can be inserted in the filter chain.
* This may be either an httpd-2.0 filter or a mod_filter harness.
* In the latter case, it contains provider and protocol information.
* In the former case, the new fields (from providers) are ignored.
*/
struct ap_filter_rec_t {
/** The registered name for this filter */
const char *name;
/** The function to call when this filter is invoked. */
ap_filter_func filter_func;
/** The function to call before the handlers are invoked. Notice
* that this function is called only for filters participating in
* the HTTP protocol. Filters for other protocols are to be
* initialized by the protocols themselves.
*/
ap_init_filter_func filter_init_func;
/** The type of filter, either AP_FTYPE_CONTENT or AP_FTYPE_CONNECTION.
* An AP_FTYPE_CONTENT filter modifies the data based on information
* found in the content. An AP_FTYPE_CONNECTION filter modifies the
* data based on the type of connection.
*/
ap_filter_type ftype;
/** The next filter_rec in the list */
struct ap_filter_rec_t *next;
/** Providers for this filter */
ap_filter_provider_t *providers;
/** Trace level for this filter */
int debug;
/** Protocol flags for this filter */
unsigned int proto_flags;
};
本文介绍了FilterObjects结构及其在处理数据过滤中的作用。每个请求都有一系列的过滤器对象,它们按顺序被调用来过滤数据。子请求会获得与主请求相同的过滤链副本。文章详细解释了ap_filter_t和ap_filter_rec_t结构,包括它们如何存储应用数据和关联请求信息。
1328

被折叠的 条评论
为什么被折叠?



