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: 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: The use of CORE_PRIVATE
On Fri, 2005-02-11 at 01:34 -0800, Greg Stein wrote: > Um... no. Why would somebody need to do that? In my experience, you might > run a sub-request. But you do *not* construct request_rec objects out of > the blue. Unless one wants to run a "canned" sub-request (through the use of some other functions), this function (and some others) is required for sub- requests as well. If "canned" sub-request functions are used, "custom" sub-request functionality is difficult to achieve without not so nice workarounds. 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. > Can you explain your use case? Why do you need that function? The new request hits an authentication URI, thus authenticating the user without the need to supply authentication headers (of basic authentication) on every request (in fact - ever). The result of authentication is stored in the application's session store for further use. I can see instances where one would run a request internally, get the result and include (parts of it) in the response. > I've said before: mod_perl is a poor example. It is too invasive with our > APIs. And if it is referring to one of those functions via defining > CORE_PRIVATE, then it rightly deserves a thrashing. OK, maybe. But there are plenty of other modules inside Apache distro itself that use CORE_PRIVATE stuff too. This comes to my original question - what is really considered "public API"? -- Bojan
Re: The use of CORE_PRIVATE
On Fri, Feb 11, 2005 at 03:00:15PM +1100, Bojan Smojver wrote: >... > For example, function ap_create_request_config() is required in order to > create > request_config for every new request. It knows about some internal sizes and > the like. It is under CORE_PRIVATE, so any module that needs to construct an > internal request is out of luck. I would think that many modules construct and > execute internal requests via ap_process_request_internal(), so this is bread > and butter stuff Um... no. Why would somebody need to do that? In my experience, you might run a sub-request. But you do *not* construct request_rec objects out of the blue. Can you explain your use case? Why do you need that function? > (for instance, I can see a use of it in > xs/Apache/RequestUtil/Apache__RequestUtil.h of mod_perl 2.0.0-RC4). I've said before: mod_perl is a poor example. It is too invasive with our APIs. And if it is referring to one of those functions via defining CORE_PRIVATE, then it rightly deserves a thrashing. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: The use of CORE_PRIVATE
Quoting Greg Stein <[EMAIL PROTECTED]>: > If you *do* need something hidden by CORE_PRIVATE, then bring it up along > with a rationale for why that thing should be made public. That's your > best solution. Get it. For example, function ap_create_request_config() is required in order to create request_config for every new request. It knows about some internal sizes and the like. It is under CORE_PRIVATE, so any module that needs to construct an internal request is out of luck. I would think that many modules construct and execute internal requests via ap_process_request_internal(), so this is bread and butter stuff (for instance, I can see a use of it in xs/Apache/RequestUtil/Apache__RequestUtil.h of mod_perl 2.0.0-RC4). I don't have the other functions that I needed handy, but I will post them back to the thread a bit later on. -- Bojan
Re: The use of CORE_PRIVATE
--On Thursday, February 10, 2005 4:57 PM -0800 Paul Querna <[EMAIL PROTECTED]> wrote: So, there is no guaranteed binary compat for any module that defines CORE_PRIVATE? I would think that any module that #define's CORE_PRIVATE is on its own and righly so. -- justin
Re: The use of CORE_PRIVATE
Greg Stein wrote: On Fri, Feb 11, 2005 at 06:26:00AM +1100, Bojan Smojver wrote: ... When I said "legal", I meant that in the technical sense. Along the lines of "if I rely on what's below CORE_PRIVATE, am I setting myself up for a disaster when those things change without notice?" Basically, are functions and other bits available under CORE_PRIVATE a fair game for module developers or are they in publicly available headers by some historical accident? Are they "standard" part of the API, but as you said for "the ones that know what they're doing" (which would then exclude me :-)? They are not part of the public API. They are very subject to removal, change, or other bastardization at a whim. So, there is no guaranteed binary compat for any module that defines CORE_PRIVATE?
Re: The use of CORE_PRIVATE
On Fri, Feb 11, 2005 at 06:26:00AM +1100, Bojan Smojver wrote: >... > When I said "legal", I meant that in the technical sense. Along the > lines of "if I rely on what's below CORE_PRIVATE, am I setting myself up > for a disaster when those things change without notice?" > > Basically, are functions and other bits available under CORE_PRIVATE a > fair game for module developers or are they in publicly available > headers by some historical accident? Are they "standard" part of the > API, but as you said for "the ones that know what they're doing" (which > would then exclude me :-)? They are not part of the public API. They are very subject to removal, change, or other bastardization at a whim. A number of modules within the httpd distribution erroneously set that #define and then use stuff. But we can always fix those things if we make changes to the "hidden" APIs. I can think of at least two points in the past where some of us have said, "this is crap! we should move all this gunk to a private header!" Great idea, but nobody has been peeved enough to do it. So yah: you run a risk of you use them. If you *do* need something hidden by CORE_PRIVATE, then bring it up along with a rationale for why that thing should be made public. That's your best solution. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: The use of CORE_PRIVATE
Bojan Smojver wrote: > "if I rely on what's below CORE_PRIVATE, am I setting myself up > for a disaster when those things change without notice?" I think the answer to this is similar to the old line "if you need to ask how much it costs you can't afford it." ;) --Geoff
Re: The use of CORE_PRIVATE
On Thu, 2005-02-10 at 12:56 -0500, Edward Rudd wrote: > On Wed, 09 Feb 2005 11:25:44 +1100, Bojan Smojver wrote: > > [snip] > > > Is it "legal" for third party modules to rely on CORE_PRIVATE in order to > > gain > > access to functions (and other bits) that would otherwise be out of bounds? > > For > > instance, I'm trying to rely on functions that help in creating > > sub-requests, > > such as ap_create_request_config(), which is only available if I define > > CORE_PRIVATE. I'm not sure if that The Right Thing To Do (TM)... > > I believe it is more of "you better know what you are doing" while using > these functions and structures. It isn't like the Linux kernel's > MODULE_LICENSE where if you are GPL you gain access to more of the kernel > then if you are not. There are no legal ramifications of using the > CORE_PRIVATE as I use it quite a bit in my mod_ftpd module on > outoforder.cc I see now that I asked this question the wrong way... Sorry :-( When I said "legal", I meant that in the technical sense. Along the lines of "if I rely on what's below CORE_PRIVATE, am I setting myself up for a disaster when those things change without notice?" Basically, are functions and other bits available under CORE_PRIVATE a fair game for module developers or are they in publicly available headers by some historical accident? Are they "standard" part of the API, but as you said for "the ones that know what they're doing" (which would then exclude me :-)? -- Bojan
Re: The use of CORE_PRIVATE
On Wed, 09 Feb 2005 11:25:44 +1100, Bojan Smojver wrote: [snip] > Is it "legal" for third party modules to rely on CORE_PRIVATE in order to gain > access to functions (and other bits) that would otherwise be out of bounds? > For > instance, I'm trying to rely on functions that help in creating sub-requests, > such as ap_create_request_config(), which is only available if I define > CORE_PRIVATE. I'm not sure if that The Right Thing To Do (TM)... I believe it is more of "you better know what you are doing" while using these functions and structures. It isn't like the Linux kernel's MODULE_LICENSE where if you are GPL you gain access to more of the kernel then if you are not. There are no legal ramifications of using the CORE_PRIVATE as I use it quite a bit in my mod_ftpd module on outoforder.cc
Re: The use of CORE_PRIVATE
Quoting Bojan Smojver <[EMAIL PROTECTED]>: > I'm trying to rely on functions that help in creating sub-requests, Actually, that would be requests as well, not just sub-requests. -- Bojan
The use of CORE_PRIVATE
I'm trying to understand the meaning of this #define a bit better. It appears in publicly available header files (by that I mean installed in a system wide location) and it basically allows access to otherwise invisible things inside Apache. Several modules in the Apache distribution are defining CORE_PRIVATE to gain such access. Is it "legal" for third party modules to rely on CORE_PRIVATE in order to gain access to functions (and other bits) that would otherwise be out of bounds? For instance, I'm trying to rely on functions that help in creating sub-requests, such as ap_create_request_config(), which is only available if I define CORE_PRIVATE. I'm not sure if that The Right Thing To Do (TM)... -- Bojan
