Return-Path: X-Original-To: apmail-httpd-modules-dev-archive@minotaur.apache.org Delivered-To: apmail-httpd-modules-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 8D426D2DE for ; Tue, 26 Jun 2012 11:55:40 +0000 (UTC) Received: (qmail 10839 invoked by uid 500); 26 Jun 2012 11:55:40 -0000 Delivered-To: apmail-httpd-modules-dev-archive@httpd.apache.org Received: (qmail 10743 invoked by uid 500); 26 Jun 2012 11:55:39 -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 10727 invoked by uid 99); 26 Jun 2012 11:55:39 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 26 Jun 2012 11:55:39 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of ohaya@cox.net designates 68.230.241.218 as permitted sender) Received: from [68.230.241.218] (HELO eastrmfepo203.cox.net) (68.230.241.218) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 26 Jun 2012 11:55:30 +0000 Received: from eastrmimpo110.cox.net ([68.230.241.223]) by eastrmfepo203.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20120626115509.ZMFX18532.eastrmfepo203.cox.net@eastrmimpo110.cox.net>; Tue, 26 Jun 2012 07:55:09 -0400 Received: from eastrmwml114 ([172.18.18.217]) by eastrmimpo110.cox.net with bizsmtp id Szv91j0014h0NJL02zv9KR; Tue, 26 Jun 2012 07:55:09 -0400 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020208.4FE9A31D.0020,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=1.1 cv=jbNBfbeyBr8Xe3UBpOVj613ZNUE1iHVw1c9l/m7poXE= c=1 sm=1 a=1AhPRghUmJAA:10 a=G8Uczd0VNMoA:10 a=X0LLrcwhTTAA:10 a=IkcTkHD0fZMA:10 a=TRy/vagDvAN6zvr8h90PzQ==:17 a=pGLkceISAAAA:8 a=kviXuzpPAAAA:8 a=j5wpqiMyaGtzX0D8IrgA:9 a=QEXdDO2ut3YA:10 a=MSl-tDqOz04A:10 a=4vB-4DCPJfMA:10 a=TRy/vagDvAN6zvr8h90PzQ==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Received: from 72.192.248.102 by webmail.east.cox.net; Tue, 26 Jun 2012 7:55:08 -0400 Message-ID: <20120626075509.V6IQ6.231621.imail@eastrmwml114> Date: Tue, 26 Jun 2012 7:55:09 -0400 From: To: modules-dev@httpd.apache.org Subject: Re: Confused about modules processing order... Cc: Sorin Manolache In-Reply-To: <4FE9A148.2050501@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) Sensitivity: Normal ---- Sorin Manolache wrote: > On 2012-06-26 13:14, ohaya@cox.net wrote: > > > > ---- Sorin Manolache wrote: > >> On 2012-06-26 03:49, ohaya@cox.net wrote: > >>> > >>> Hi, > >>> > >>> I have my small prototype module, which I implemented starting with the mod_headers.c source, working. The changes that I did to the original source were to add some code in the insert_filter hook to inject an additional header into the request. > >>> > >>> That seems to work ok with a "vanilla" Apache configuration. > >>> > >>> I want to be able to make my modified module work together with another module, provided by Oracle (the Oracle Access Manager webgate, aka "webgate"). > >>> > >>> However, after I add the directives into the Apache httpd.conf to enable the webgate, it appears that, on incoming requests, the webgate processing occurs, but my code in the modified mod_headers module is not called at all :(!! > >>> > >>> > >>> Here's the last part of my modified mod_headers.c: > >>> > >>> static void register_hooks(apr_pool_t *p) > >>> { > >>> printf("mod_headers-jl V0.13 - use LIBCURL instead of OAM ASDK-process response from callCurl\n"); > >>> printf("In register_hooks\n"); > >>> ap_register_output_filter("FIXUP_HEADERS_OUT", ap_headers_output_filter, > >>> NULL, AP_FTYPE_CONTENT_SET); > >>> ap_register_output_filter("FIXUP_HEADERS_ERR", ap_headers_error_filter, > >>> NULL, AP_FTYPE_CONTENT_SET); > >>> ap_hook_pre_config(header_pre_config,NULL,NULL,APR_HOOK_MIDDLE); > >>> ap_hook_post_config(header_post_config,NULL,NULL,APR_HOOK_MIDDLE); > >>> ap_hook_insert_filter(ap_headers_insert_output_filter, NULL, NULL, APR_HOOK_LAST); > >>> ap_hook_insert_error_filter(ap_headers_insert_error_filter, > >>> NULL, NULL, APR_HOOK_LAST); > >>> ap_hook_fixups(ap_headers_fixup, NULL, NULL, APR_HOOK_LAST); > >>> ap_hook_post_read_request(ap_headers_early, NULL, NULL, APR_HOOK_FIRST); > >>> } > >>> > >>> module AP_MODULE_DECLARE_DATA headers_module = > >>> { > >>> STANDARD20_MODULE_STUFF, > >>> create_headers_dir_config, /* dir config creater */ > >>> merge_headers_config, /* dir merger --- default is to override */ > >>> NULL, /* server config */ > >>> NULL, /* merge server configs */ > >>> headers_cmds, /* command apr_table_t */ > >>> register_hooks /* register hooks */ > >>> }; > >>> > >>> > >>> The code I added is in the "ap_headers_insert_output_filter()" function. > >>> > >>> > >>> I did an "export SHOW_HOOKS=1" and ran the Apache, and I see this for the modified mod_headers: > >>> > >>> Registering hooks for mod_headers.c > >>> mod_headers-jl V0.13 - use LIBCURL instead of OAM ASDK-process response from callCurl > >>> In register_hooks > >>> Hooked pre_config > >>> Hooked post_config > >>> Hooked insert_filter > >>> Hooked insert_error_filter > >>> Hooked fixups > >>> Hooked post_read_request > >>> > >>> > >>> And for webgate, I see: > >>> > >>> Registering hooks for apache2entry_web_gate.cpp > >>> Hooked post_config > >>> Hooked handler > >>> Hooked check_user_id > >>> Hooked auth_checker > >>> > >>> > >>> I thought that the handler functions are called almost last part of the processing (content generation), and my code is hooked to insert_filter, which I thought occurs earlier than content generation, so shouldn't my code get processed BEFORE Apache attempts to process the webgate functions? > >>> > >>> How can I get my code to process before the webgate does? > >>> > >> > >> insert_filter is run between the fixups and the handler hooks. > >> > >> Try to identify who is producing the variables that you need, in which > >> phase they are available at the earliest. Then identify which part of > >> web_gate hijacks the processing such that your code is not executed > >> anymore. I suppose it is one of web_gate's auth_checker or > >> check_user_id. If it was the web_gate handler then your code would have > >> run before. > >> > >> Sorin > > > > > > Hi Sorin, > > > > I posted a later msg that I've been trying do something along the lines that you said: > > > > "I've been doing more testing, and it appears that the insert_filter hook (the > > "ap_headers_insert_output_filter()" function) is the only place where I can put > > my code where it has access to the variables that it needs to do the processing > > that I'm doing. > > > > The problem is that if that other Oracle module is enabled in the Apache, it > > runs before my code, and I can't get the insert_filter hook (my function) to get > > processed before the Oracle module " > > The SSL variables are set in the fixups hook by mod_ssl. The fixups hook > is run _after_ check_user_id and auth_checker. So you cannot rely on > mod_ssl to populate the environment with the variables. I guess you'll > have to get those variables yourself, before Oracle's check_user_id and > auth_checker hooks. > > Sorin Hi, The original mod_headers code has a hook for fixups. If I added an "after" string in the code that registers my fixup function, with the name of the webgate, would that cause my modified mod_headers to run before the webgate? Also can you clarify/expand on what you mean by " you'll have to get those variables yourself"? I think that I'm currently getting them using env->setproc or something like that. Jim