Re: The use of CORE_PRIVATE
On Sun, 2005-02-13 at 16:28 +1100, Bojan Smojver wrote: I'm not sure why constructing a request would be so unusual. Application servers running inside Apache may need to do this stuff all the time. Just a little clarification here. The text here: http://httpd.apache.org/docs-2.0/developer/request.html#processing Does mention generated requests in relation to modules: All requests pass through ap_process_request_internal() in request.c, including subrequests and redirects. If a module doesn't pass generated requests through this code, the author is cautioned that the module may be broken by future changes to request processing. Therefore, I was under the impression that this is a normal thing for modules to do (i.e. generate requests). Unfortunately, not all functions required to do so fall under the public API. Maybe I should approach my problem differently. Maybe I should be writing a patch for yet non-existent function ap_generate_request(), along the lines of that mod_perl function. Then this new function becomes public and CORE_PRIVATE remains truly private... And, all module writers can rely on this function for creation of vanilla requests. In any event, I think separating everything under CORE_PRIVATE into separate, non-installable headers is the right thing to do. Would patches along those lines be welcome? -- Bojan
Re: [PATCH] Win32: install service in rewrite args rather than post_config?
From: Bill Stoddard Bill R correctly identified the reason I'd like to see the service install occur before post-config. And if there is an error here do what? Also what if one has never read the source code, before post-config means nothing to one who may know the answer to a simple question. If the last thing your installer does is install the service, the service install will fail if there is a problem with httpd.conf. Yes and you want to do what here? The most likely problem is that some other service is using port 80 (or port 443, or whatever port you want httpd to listen on). Yes and you want to do what here? You still have not said A This is happening to me (users) Port already used B And if A I (users) want to do this Tell Users - never install Tell Users - after Install Fix the problem, try again? C All A and B but for a developer Tell users/developer what and when, and then do what? So once again, what is the real problem (user or developer) and what to you want or wish to do about it? Jeff
Apache 2.0.53/Win32/.msi+.exe installers
Dearest testing community; at http://httpd.apache.org/dev/dist/ you will find new Win32 installers for the apache_2.0.53 release, and the new Win32 source tarball (buildable from command line on VC5+ with nmake -f makefile.win). Please validate and report, before I push this out live. Mea Culpa this is running behind, we have both the svn change which I had to contend with, an incomplete apr-iconv release which had to be completed, and this is the *first* release of 2.0.x using the InstallShield X product (previous releases were created with InstallShield for Windows Installer.) As with most 'automatic conversions' not everything that is converted magically becomes magically correct. Although it seems this installer is stable, wider testing is needed due to the changeover. Please cc: me in all replies to avoid moderation. Thanks! Bill
Re: [PATCH] Win32: install service in rewrite args rather than post_config?
At 06:00 PM 2/12/2005, Bill Stoddard wrote: Bill R correctly identified the reason I'd like to see the service install occur before post-config. If the last thing your installer does is install the service, the service install will fail if there is a problem with httpd.conf. The most likely problem is that some other service is using port 80 (or port 443, or whatever port you want httpd to listen on). That and other issues. I have a couple theories on this... * Solve the port 80 (443...) problem simply by testing those ports in real_features.dll, a stub which our .msi invokes to test other real-world issues, today. Add the choice of ports (default: 80) and run the user in a circle till they choose a valid port. * If this is possible; Pipe the service install output to a log file. Present the user the results of that log file upon exit. Hopefully, this provides some feedback of why it did not install. [This is not as trivial in .msi as it might sound.] There are a few other changes I'm working on to the installer which will create other failure cases, such as running the service as another user. We can't safely move around a p/w for that account without the possibility of it being snooped. So if run-as-user is selected, we won't be starting the installed service, but taking them to the service control panel after creating that service for them to enter the p/w. We also need to axe (force to shutdown) the ApacheMonitor.exe taskbar applet on uninstall/upgrade/etc. Working on that. Finally the ApacheMonitor needs an extra option to dredge out the Application Event MMC view, just like it can bring up the Services view, or it's own expanded view. Not to mention the green light/red light indicator is broken in the taskbar. My theory is, if any service set to start 'Automatic' is not started, the light should never be green. Oh, and finally, we really shouldn't invert the icon color next to the service name in the quick view when it has mouse focus. The service name can be inverted, but the inversion changes redgreen lol. All this and more as I have cycles, help is always welcome. Bill
Re: The use of CORE_PRIVATE
Quoting Bojan Smojver [EMAIL PROTECTED]: If canned sub-request functions are used, custom sub-request functionality is difficult to achieve without not so nice workarounds. The above comment is in relation to server/request.c file and functions defined there. There is a static function make_sub_request(), which is obviously not visible from the public API. In order to get to that function to contruct a request, one has to call either of ap_sub_req_method_uri(), ap_sub_req_lookup_dirent() or ap_sub_req_lookup_file(). However, all of these are canned functions that already call either ap_run_quick_handler() or ap_process_request_internal(), before giving the module's author a chance to customise the request further (e.g. add more headers and such), before calling any hooks. If somehow make_sub_request() could be a public function ap_make_sub_request() or something similar, all my issues would go away... -- Bojan
Re: Apache 2.0.53/Win32/.msi+.exe installers
On Sun, 13 Feb 2005, William A. Rowe, Jr. wrote: Dearest testing community; at http://httpd.apache.org/dev/dist/ you will find new Win32 installers for the apache_2.0.53 release, and the new Win32 source tarball (buildable from command line on VC5+ with nmake -f makefile.win). Please validate and report, before I push this out live. Mea Culpa this is running behind, we have both the svn change which I had to contend with, an incomplete apr-iconv release which had to be completed, and this is the *first* release of 2.0.x using the InstallShield X product (previous releases were created with InstallShield for Windows Installer.) As with most 'automatic conversions' not everything that is converted magically becomes magically correct. Although it seems this installer is stable, wider testing is needed due to the changeover. Please cc: me in all replies to avoid moderation. Thanks! Bill For me, both the .msi installer and the build from the sources (using VC++ 6) worked fine. -- best regards, randy kobes
