Return-Path: Delivered-To: apmail-httpd-modules-dev-archive@minotaur.apache.org Received: (qmail 43340 invoked from network); 2 Apr 2009 14:00:30 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 2 Apr 2009 14:00:30 -0000 Received: (qmail 6899 invoked by uid 500); 2 Apr 2009 14:00:30 -0000 Delivered-To: apmail-httpd-modules-dev-archive@httpd.apache.org Received: (qmail 6864 invoked by uid 500); 2 Apr 2009 14:00:29 -0000 Mailing-List: contact modules-dev-help@httpd.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: modules-dev@httpd.apache.org Delivered-To: mailing list modules-dev@httpd.apache.org Received: (qmail 6854 invoked by uid 99); 2 Apr 2009 14:00:29 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Apr 2009 14:00:29 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of sorinm@gmail.com designates 209.85.219.162 as permitted sender) Received: from [209.85.219.162] (HELO mail-ew0-f162.google.com) (209.85.219.162) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Apr 2009 14:00:22 +0000 Received: by ewy6 with SMTP id 6so528993ewy.24 for ; Thu, 02 Apr 2009 07:00:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=/oDCQxeBS6n3jRVuqLZofaGrx0zvgbSXF05KaKB0qTQ=; b=PBTGfr7Rbp6sSEazptPtVh4gvi0JaQg9FDnfvo0X1fd24pyzJuwW2t4HRJWD0XB98M GurOZnPjbKUUtiLNlqFBl0O04hjAs1Mo58pNyjGnA6Yif+CPa55HlV1j1zfz1HIsntk6 cqWDwU/1UfYP5OUwLfiCoUaRcDSJ4QSPv0w3Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=IJt6z4DIjfBqSMxaHAPs5r+E8hG0gbmuusZ8hiwQts9apG0ov4OT88ZxhWAMopR9TX 35S8RM25VO8akd6Z36dnPf4CuhCRTLMuboWUdg0phIKmdFDC3D9lGDXT3WxGn5lztz8F zV13EVmJ1UlFUHz8C/9GNFMxz+bmQUhFjfdWs= MIME-Version: 1.0 Received: by 10.210.16.10 with SMTP id 10mr5428160ebp.26.1238680801710; Thu, 02 Apr 2009 07:00:01 -0700 (PDT) In-Reply-To: <22848174.post@talk.nabble.com> References: <22845761.post@talk.nabble.com> <20170a030904020512w7b25e4bdwc8fc4ef1e4d8ae38@mail.gmail.com> <22848174.post@talk.nabble.com> Date: Thu, 2 Apr 2009 16:00:01 +0200 Message-ID: <20170a030904020700l3507d5c4p8276c8fd1a02fd9f@mail.gmail.com> Subject: Re: About the order of the processing of the http request From: Sorin Manolache To: modules-dev@httpd.apache.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org On Thu, Apr 2, 2009 at 15:44, Xiaobin wrote: > > > > Sorin Manolache wrote: >> >> On Thu, Apr 2, 2009 at 13:28, Xiaobin wrote: >>> >>> Hi, everyone. >>> >>> I new to modlue developemnt of the Apache http server, and I have googled >>> this question and can't find the answer. Hope you can help me. Thx. >>> >>> I am confused with the order of the processing of the http request. >>> >>> Without the input/output filters, the order seems quick clear, when one >>> http >>> request comes, it will go through different kinds of hooks like "map to >>> storage", "fixups" and "handler". And we can set some handlers to deal >>> with >>> these hooks. >>> >>> But what's the order after the introduction of the filter mechanism? >>> >>> When will the input filters begin to work? >>> After the handlers of the fixups hook has been called and before the >>> handlers of the "handler" hook begin to work? >>> Or in some other order? >>> And how can we specify the order of the input filters? >>> >>> And for the output filters, when did they begin to work? Before or after >>> the >>> "log transaction" hook ? >>> And also how can we specify the order of the output filters? >>> >>> Thank you very much for your help! >> >> There are several types of filters: network, protocol, connection, >> resource (the list is not exhaustive, check util_filters.h in the >> apache sources). >> >> The input headers of the request are read after the create_request >> hook and before the post_read_request, quick_handler, translate_name, >> map_to_storage, header_parser, access_checker, ..., fixups, >> insert_filter, and handler hooks. >> >> The output headers of the request are written during the handler >> execution. >> >> When the headers are read/written, the protocol filters are called. >> >> The resource input/output filters are called only when you explicitly >> read/write the body of the request. If you add filters with the >> SetInputFilter/SetOutputFilter directives, the filter is added in the >> insert_filter hook. This one is called after fixups and before >> handler. Thus, you cannot use a filter added with >> SetInputFilter/SetOutputFilter before the handler hook. >> >> log_transaction is called after the request was served and the >> response was written to the socket and the socket flushed. >> >> If the filters are of the same type, they are run in the order they >> were added. If they are of different types, then I think their type >> takes precedence, but I am not sure of that. For output filters, >> resource filters are called before network filters. >> >> S >> -- >> A: Because it reverses the logical flow of conversation. >> Q: Why is top-posting frowned upon? >> A: Top-posting. >> Q: What is the most annoying thing in e-mail? >> >> > > > Thank you very much! > > So, the resouce/content input filter will be called after fixups hook and > before > handler hook, is this right? No. They are run _after_ the fixup hook. They are invoked _from_ (not before) the handler hook. In the handler you call ap_get_brigade and it is this call that invokes the input filters. Remember that the filters are not automatically invoked. You need to call ap_get_brigade to call the input filters and ap_pass_brigade to call the output filters. So simply adding a filter in translate_name will not read anything. If, for example, you don't care about the body of the POST request and you don't call ap_get_brigade from the handler, the input filters are not called, even if they are present. > If this is right, is it possible to make the input filter run earlier? Like > after the translate_name hook and before the map_to_storage hook? Yes, it is possible. You hook the translate_name or the map_to_storage hook. In your callback you call ap_add_input_filter, you do what you want, and then you remove the filters. If you do not remove them, insert_filter in ap_invoke_handler (which is called after fixups) will add them a second time and then chances are that you won't get what you want. > And I am not so understand about this part: > "Thus, you cannot use a filter added with SetInputFilter/SetOutputFilter > before the handler hook." > > Do you mean that in the httpd.conf file, the SetHandler instruction should > be set before the SetInputFilter/SetOutputFilter instructions ? No. It means that code that is run before the handler hook works in the _absence_ of the filters. The filters are added just before the handler hook. Only the handler hook will benefit of the presence of the filters. S -- A: Because it reverses the logical flow of conversation. Q: Why is top-posting frowned upon? A: Top-posting. Q: What is the most annoying thing in e-mail?