Chinaunix首页 | 论坛 | 博客
  • 博客访问: 4489487
  • 博文数量: 192
  • 博客积分: 10014
  • 博客等级: 上将
  • 技术积分: 8232
  • 用 户 组: 普通用户
  • 注册时间: 2006-07-21 00:22
文章分类

全部博文(192)

文章存档

2011年(4)

2009年(14)

2008年(174)

我的朋友

分类: C/C++

2008-03-08 23:18:00

本文转自:
 
原文如下:
 
Apache模块开发/用C语言扩展apache(1:简述)
by linux_prog
   Apache是一个非常稳定而且非常open的web server,它的很多功能都可以通过plugin的方式去扩展。
比如:mod_proxy使得apache可以作代理, mod_rewrite使得apache可以实现非常强大的url mapping和rewritting
功能,你是否也想自己来开发一个apache module呢?网上这方面的文章非常的少,而且全是E文,
希望我的这篇文章能够给你一些实质性的帮助。
   开发apache module之前,我们有必要先分析一下其源代码。
   $ cd httpd-2.2.4/
   $ ls
   其中:server/目录是apache核心程序的代码
         include/目录存放主要的头文件
         srclib/目录存放apr和apr-util代码(这两个是什么,后面介绍)
         modules/目录下存放目前已经有的各种module(可以看看这些代码先)
  
   $ cd include/
   先分析一下apache的头文件
   $ vi httpd.h
   第766行,这个结构非常的重要,后面编写模块时都要用到这个结构,所以分析一下。
   每个http request都会对应这个结构的一个实例。
   由于apache的源代码都有很详细的英文注释,所以我也不翻译了。

struct request_rec {
    /** The pool associated with the request */
    //内存管理池,后面讲apr时会讲到

    apr_pool_t *pool;
    /** The connection to the client */
    conn_rec *connection;
    /** The virtual host for this request */
    server_rec *server;

    /** Pointer to the redirected request if this is an external redirect */
    request_rec *next;
    /** Pointer to the previous request if this is an internal redirect */
    request_rec *prev;

    /** Pointer to the main request if this is a sub-request
     * (see http_request.h) */

    request_rec *main;

    /* Info about the request itself… we begin with stuff that only
     * protocol.c should ever touch…
     */

    /** First line of request */
    char *the_request;
    /** HTTP/0.9, ”simple” request (e.g. GET /foo\n w/no headers) */
    int assbackwards;
    /** A proxy request (calculated during post_read_request/translate_name)
     * possible values PROXYREQ_NONE, PROXYREQ_PROXY, PROXYREQ_REVERSE,
     * PROXYREQ_RESPONSE
     */

    int proxyreq;
    /** HEAD request, as opposed to GET */
    int header_only;
    /** Protocol string, as given to us, or HTTP/0.9 */
    char *protocol;
    /** Protocol version number of protocol; 1.1 = 1001 */
    int proto_num;
    /** Host, as set by full URI or Host: */
    const char *hostname;

    /** Time when the request started */
    apr_time_t request_time;

    /** Status line, if set by script */
    const char *status_line;
    /** Status line */
    int status;

    /* Request method, two ways; also, protocol, etc.. Outside of protocol.c,
     * look, but don’t touch.
     */


    /** Request method (eg. GET, HEAD, POST, etc.) */
    const char *method;
    /** M_GET, M_POST, etc. */
    int method_number;

    /**
     * ’allowed’ is a bitvector of the allowed methods.
     *
     * A handler must ensure that the request method is one that
     * it is capable of handling. Generally modules should DECLINE
     * any request methods they do not handle. Prior to aborting the
     * handler like this the handler should set r->allowed to the list
     * of methods that it is willing to handle. This bitvector is used
     * to construct the ”Allow:” header required for OPTIONS requests,
     * and HTTP_METHOD_NOT_ALLOWED and HTTP_NOT_IMPLEMENTED status codes.
     *
     * Since the default_handler deals with OPTIONS, all modules can
     * usually decline to deal with OPTIONS. TRACE is always allowed,
     * modules don’t need to set it explicitly.
     *
     * Since the default_handler will always handle a GET, a
     * module which does *not* implement GET should probably return
     * HTTP_METHOD_NOT_ALLOWED. Unfortunately this means that a Script GET
     * handler can’t be installed by mod_actions.
     */

    apr_int64_t allowed;
    /** Array of extension methods */
    apr_array_header_t *allowed_xmethods;
    /** List of allowed methods */
    ap_method_list_t *allowed_methods;

    /** byte count in stream is for body */
    apr_off_t sent_bodyct;
    /** body byte count, for easy access */
    apr_off_t bytes_sent;
    /** Last modified time of the requested resource */
    apr_time_t mtime;

    /* HTTP/1.1 connection-level features */

    /** sending chunked transfer-coding */
    int chunked;
    /** The Range: header */
    const char *range;
    /** The ”real” content length */
    apr_off_t clength;

    /** Remaining bytes left to read from the request body */
    apr_off_t remaining;
    /** Number of bytes that have been read from the request body */
    apr_off_t read_length;
    /** Method for reading the request body
     * (eg. REQUEST_CHUNKED_ERROR, REQUEST_NO_BODY,
     * REQUEST_CHUNKED_DECHUNK, etc…) */

    int read_body;
    /** reading chunked transfer-coding */
    int read_chunked;
    /** is client waiting for a 100 response */
    unsigned expecting_100;

    /* MIME header environments, in and out. Also, an array containing
     * environment variables to be passed to subprocesses, so people can
     * write modules to add to that environment.
     *
     * The difference between headers_out and err_headers_out is that the
     * latter are printed even on error, and persist across internal redirects
     * (so the headers printed for ErrorDocument handlers will have them).
     *
     * The ’notes’ apr_table_t is for notes from one module to another, with no
     * other set purpose in mind…
     */


    /** MIME header environment from the request */
    apr_table_t *headers_in;
    /** MIME header environment for the response */
    apr_table_t *headers_out;
    /** MIME header environment for the response, printed even on errors and
     * persist across internal redirects */

    apr_table_t *err_headers_out;
    /** Array of environment variables to be used for sub processes */
    apr_table_t *subprocess_env;
    /** Notes from one module to another */
    apr_table_t *notes;

    /* content_type, handler, content_encoding, and all content_languages
     * MUST be lowercased strings. They may be pointers to static strings;
     * they should not be modified in place.
     */

    /** The content-type for the current request */
    const char *content_type; /* Break these out — we dispatch on ’em */
    /** The handler string that we use to call a handler function */
    const char *handler; /* What we *really* dispatch on */

    /** How to encode the data */
    const char *content_encoding;
    /** Array of strings representing the content languages */
    apr_array_header_t *content_languages;

    /** variant list validator (if negotiated) */
    char *vlist_validator;
   
    /** If an authentication check was made, this gets set to the user name. */
    char *user;
    /** If an authentication check was made, this gets set to the auth type. */
    char *ap_auth_type;

    /** This response can not be cached */
    int no_cache;
    /** There is no local copy of this response */
    int no_local_copy;

    /* What object is being requested (either directly, or via include
     * or content-negotiation mapping).
     */


    /** The URI without any parsing performed */
    char *unparsed_uri;
    /** The path portion of the URI */
    char *uri;
    /** The filename on disk corresponding to this response */
    char *filename;
    /* XXX: What does this mean Please define ”canonicalize” -aaron */
    /** The true filename, we canonicalize r->filename if these don’t match */
    char *canonical_filename;
    /** The PATH_INFO extracted from this request */
    char *path_info;
    /** The QUERY_ARGS extracted from this request */
    char *args;
    /** finfo.protection (st_mode) set to zero if no such file */
    apr_finfo_t finfo;
    /** A struct containing the components of URI */
    apr_uri_t parsed_uri;

    /**
     * Flag for the handler to accept or reject path_info on
     * the current request. All modules should respect the
     * AP_REQ_ACCEPT_PATH_INFO and AP_REQ_REJECT_PATH_INFO
     * values, while AP_REQ_DEFAULT_PATH_INFO indicates they
     * may follow existing conventions. This is set to the
     * user’s preference upon HOOK_VERY_FIRST of the fixups.
     */

    int used_path_info;

    /* Various other config info which may change with .htaccess files
     * These are config vectors, with one void* pointer for each module
     * (the thing pointed to being the module’s business).
     */


    /** Options set in config files, etc. */
    struct ap_conf_vector_t *per_dir_config;
    /** Notes on *this* request */
    struct ap_conf_vector_t *request_config;

    /**
     * A linked list of the .htaccess configuration directives
     * accessed by this request.
     * N.B. always add to the head of the list, _never_ to the end.
     * that way, a sub request’s list can (temporarily) point to a parent’s list
     */

    const struct htaccess_result *htaccess;

    /** A list of output filters to be used for this request */
    struct ap_filter_t *output_filters;
    /** A list of input filters to be used for this request */
    struct ap_filter_t *input_filters;

    /** A list of protocol level output filters to be used for this
     * request */

    struct ap_filter_t *proto_output_filters;
    /** A list of protocol level input filters to be used for this
     * request */

    struct ap_filter_t *proto_input_filters;

    /** A flag to determine if the eos bucket has been sent yet */
    int eos_sent;

/* Things placed at the end of the record to avoid breaking binary
 * compatibility. It would be nice to remember to reorder the entire
 * record to improve 64bit alignment the next time we need to break
 * binary compatibility for some other reason.
 */

};

可以看到源码中有很多apr_开头的结构,这个是什么呢?下节介绍一下。

阅读(1467) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~